分佈式系統中的容錯造成區塊鏈

想知道更多關於區塊鏈技術知識，請百度【鏈客區塊鏈技術問答社區】
鏈客，有問必答！

分佈式系統是實現高可伸縮性，局部性和可用性的基本概念。然而，另外一方面，當從客戶端查看時，整個系統須要不少首創性才能看起來一致。另外，聽說構建具備完整特徵的分佈式系統幾乎是不可能的，而且有必要選擇應用程序應該強調哪些性能。

除了描述這些分佈式系統的特性外，咱們還描述了具備高性能的區塊鏈的特性。最後，經過總結容錯屬性，咱們將進一步探索區塊鏈的更大潛力，並但願經過討論每一個高級區塊鏈項目（如Tendermint）全面解釋MOLD應該瞄準的系統。

1. 簡介（容錯概述以及整體流程）

與單個系統不一樣，分佈式系統存在部分故障。單個系統的總體故障每每會致使整個系統崩潰。另外一方面，在部分故障中，系統能夠在從部分故障中恢復的同時繼續操做而不會嚴重影響總體性能。

在本文中，按照如下順序，咱們將解釋容錯;即便系統的一部分發生故障，系統也能夠繼續處理。

・什麼樣的屬性是容錯的
・什麼樣的失敗以及它們如何被分類
・如何在分佈式系統中實現容錯
・關於溝通失敗
・「可靠的多播」，增長了進程的抵抗力
・關於分佈式提交問題

1. 什麼是容錯？

容錯

容錯定義以下

即便發生故障也可以忍受服務
另外，具備容錯性的系統有時被稱爲高可靠性系統，而且與可靠性系統相關的要求分爲如下四種。

失敗模型

分佈式系統中進程的典型故障以下：

通訊鏈路的故障也是分類的。

例如，對於分佈式的失敗，可能會發生虛假消息的傳遞，所以最難以處理。

冗餘能夠隱藏故障。這很容易理解，例如考慮到哺乳動物有兩隻眼睛，耳朵和肺。即便這些分佈式器官中的一些失效，你也能夠在隱藏故障的同時使用該系統。這稱爲物理冗餘。冗餘有三種類型：信息冗餘，時間冗餘和物理冗餘。

1. 流程彈性

在描述容錯以後，咱們考慮如何實現容錯。

進程複製

典型的方法是進程複製。在組中建立（複製）相同的進程稱爲複製。經過在分佈式系統中複製，即便在部分故障的狀況下，也能夠經過正常過程提供服務。咱們將複製過程稱爲副本。

複用（複製）有兩種方法以下。

・主基礎協議（被動複製）
・重複寫入協議（PositiveReplication）

在前的中，只有主副本處理來自客戶端的消息，而其餘副本備份主進程。雖然複製品之間的處理結果沒有不一致，而且通訊功能的實現更容易，可是主複製品的故障須要選擇算法，而且處理有些複雜。

在後一種狀況下，全部副本都會從客戶端接收和處理消息。此時，基於消息的處理須要總排序和原子性的兩個屬性。所以，原子多播須要更復雜的通訊功能。

k容錯

在重複寫入協議中，聽說具備k個容錯，即便它們失敗，k個組件也能正常移動。若是你有分佈式故障，則至少須要2k+1個進程才能具備k容錯能力。

原子組播問題

做爲上述複製模型的前提，存在全部請求必須以相同順序到達全部服務器的條件。這稱爲原子多播問題。這將在第5章中詳細討論。

流程之間的協議

進程之間協議的問題對於賦予分佈式系統容錯性是相當重要的。分佈式協議算法的目的是在有限數量的步驟中達成共識，以實現彼此之間沒有失敗的過程，而且在表明性過程當中存在通常分佈式的問題。

分佈式的通常問題

在具備k個錯誤進程的系統中，僅當存在2k+1個或更多正常進程而且總體上存在N=< 3k+1個進程時才達成協議。換句話說，只有超過三分之二的進程正常工做才能達成協議。（若是小於該值，則可能會因失敗的過程而受到欺騙。）

附錄：關於容錯所需的正常節點數

對於許多協議，具備分佈式阻塞的最大容許節點數被稱爲1/3。緣由將在下面簡要描述。

設「N」爲節點總數，「F」爲分佈式節點，「T」爲正常共識所需的節點數。

例如，假設「N-F」的正常節點被分紅相同的數字，而且數字表示以下。
(N-F) / 2

因爲「F」的分佈式節點具備任意行爲，爲了正常地達成共識，必須知足如下表達式。

T > (N-F)/2 + F ・・・①

此外，考慮到F的全部分佈式節點都處於離線狀態的狀況，其餘正常節點能夠採用共識，所以如下表達式成立。

N-F ≥ T ・・・②

從①·②，

N−F > (N−F)/2 + F
∴F < N3

基於上述，當總節點中分佈式節點的數量小於1/3時，能夠正常地達成共識。

4.可靠的客戶端-服務器通訊

到目前爲止，咱們討論了分佈式系統中進程的容錯能力，並瞭解了複製。本章討論了通訊鏈路上容錯的介紹。

P2P通訊

分佈式系統中的通訊基礎是鏈接一個進程和另外一個進程的點對點通訊（一對一通訊）。

TCP

TCP：實現可靠通訊的點對點通訊

TCP具備序列號，定時器，校驗和，確認，重傳控制，擁塞控制等機制。例如，因爲丟失消息而致使的遺漏失敗能夠經過包括TCP序列號的確認和基於確認的重傳控制來處理。

發生故障時的RPC（遠程過程調用）

RPC的目的是經過本地過程調用的形式實現進程間通訊而不須要意識到通訊部分。在使用RPC的分佈式系統中可能會發生五個障礙。

1. 客戶端沒法找到服務器。
2. 從客戶端到服務器的請求消息將丟失。
3. 收到請求後服務器崩潰。
4. 從服務器到客戶端的響應消息將丟失。
5. 在客戶端發送請求消息後發生故障。

做爲對每一個的對策，存在設置異常處理和計時器（時間限制）的方法。

5.可靠的團隊溝通

咱們在前一章中專一於一對一通訊，所以咱們在此解釋一對多多播通訊的高可靠性。在分佈式系統中，重要的是發送消息而不會泄漏，包括訂單到彼此的服務器。

在沒有故障的狀況下可靠的多播

考慮按順序向每一個成員發送消息。

發送方首先將多播消息保存在手頭的歷史存儲器中。此外，發送方從接收方接收傳輸確認通知（ACK）。在ACK中，輸入並返回最後一個消息標識符已完成傳輸。若是因爲消息丟失等而沒法接收到包含預期標識符的ACK，則發送方從新發送該消息。

確保來自發件人的郵件以相同的順序傳遞給全部進程。

在分佈式系統中，不是「一個過程」

具備「什麼時候」發送方「在消息傳遞期間失敗，該消息被傳遞到全部剩餘進程或被忽略」的屬性的可靠多播稱爲虛擬同步。

此外，做爲虛擬同步並以總順序執行消息傳遞的通訊稱爲原子多播。

虛擬同步的一個實現示例是Isis。Isis保留並轉移mmessageM進行處理，直到它知道全部成員都收到了消息M.

6.分佈式提交

推廣原子多播問題的問題稱爲分佈式提交問題。

原子提交

有必要終始如一地判斷不一樣的相似站點的進程是否一致地提交或停止。這種操做稱爲原子提交。

6–1.兩階段提交協議（2PC）

兩階段提交協議（2PC）是實現原子提交的典型方法。顧名思義，每一個階段包括兩個步驟，組織以下。

（第1階段【投票階段】）

組織者向全部參與者發送VOTE_REQUEST消息

1. 收到VOTE_REQUEST消息的參與者若是可以提交其交易並經過發送VOTE_ABORT消息進行投票（若是須要停止），則向組織者發送VOTE_COMMT消息。

（第2階段[提交階段]）

1. 組織者收集全部參與者的投票。若是全部投票都是COMMIT，咱們本身承諾並向全部參與者發送GLOBAL_COMMIT消息。若是ABORT甚至多於一個，它決定停止交易併發送GLOBAL_ABORT消息。

4.參與者等待來自組織者的消息，若是它是GLOBAL_COMMIT本地，則提交，若是它是GLOBAL_ABORT則丟棄該交易。

在整個過程當中，組織者和參與者進行以下狀態轉換。

阻止提交協議

上述兩階段提交協議存在很大問題。當組織者在階段3中失敗而且全部參與者都在等待來自組織者的消息時。，參與者不能合做決定應該最終採起的行動決定。據此，兩階段提交被稱爲阻塞提交協議。

實際上，在兩階段提交中阻塞自身不多發生，所以它沒有被大量使用，可是設計了三階段提交協議做爲避免阻塞的解決方案。

6–2.三階段提交

與兩階段提交協議不一樣，三階段提交協議知足如下兩個條件。[Skeen和Stonebraker，1983]指出，這兩個條件對於沒有阻塞的提交協議是必要和充分的。

1. 沒有直接進入COMMIT狀態或ABORT狀態的狀況。
2. 沒有可能作出最終決定，也沒有轉換到COMMIT狀態的狀態。

SKEEN,D.andSTONEBRAKER,M」AFormalModelofCrashRecoveryinaDistributedSystem.」IEEETrans.Softw.Eng.,Mar.1983

具體地，在兩階段提交的兩個階段之間提供PRECOMMIT狀態。

整個參與者和組織者改變狀態以下。

兩階段提交的最大區別是全部進程都返回INIT，ABORT，PRECOMMIT狀態。因爲它永遠不會處於READY狀態，所以剩餘的進程始終作出最終決定，而且能夠充當非阻塞協議。
三階段提交僅僅是一個概念表示，即便組織者失敗，也沒有正常工做的機制。然而，在區塊鏈出現以後，它的歷史將會發生很大變化。Tendermint項目經過在區塊鏈中採用三階段提交來實現非阻塞協議。

7.區塊鏈中的容錯

最後，基於上述內容，咱們還將參考分佈式區塊鏈系統中的容錯。

7–1.區塊鏈容錯

區塊鏈的容錯性很高。讓咱們根據第2章中分類的四個可靠性要求，仔細研究區塊鏈的性質。

區塊鏈系統中止運行的時間和數量不多。特別是在比特幣網絡中，能夠說不多有高可用性和可靠性，由於即便某些節點出現故障，它也能實現零停機並繼續正常運行。

接下來，關於安全性，當系統在區塊鏈網絡中不能正常運行時，將出現諸如「交易未被處理和阻塞」，「網絡中的節點之間不共享信息以及分叉的分塊」之類的問題。後者極有可能致使重大麻煩。

關於可維護性，能夠說社區很容易劃分，好比像比特幣這樣的公共區塊鏈，而且難以從中恢復。比特幣網絡能夠高度讚揚，由於它具備高可用性和可靠性，所以不須要恢復，但若是你但願具備可維護性，則應考慮選擇私有鏈或聯盟鏈。

此外，區塊鏈很是有意義，由於它爲分佈式斷層提供了有效的解決方案，這被認爲是最難處理的。具體來講，它是以PoW等爲表明的一致性算法……經過造成激勵結構來處理分佈式的通常問題;經過維持/貢獻而不是基於博弈論破壞網絡的行動，礦工凸輪得到更多利潤的算法。應該注意的是，諸如硬叉之類的新問題正在發生，然而，能夠說它已經取得了必定的成功。此外，
Hyperledger採用的PBFT也經過設置領導節點確認投票來實現高分佈式容錯。

7–2.Blcokchain流程彈性

考慮如何在容錯描述以後實現容錯。

首先，有兩種處理複製的方法。

1.主要基礎協議
2.重複寫入協議

採用1的主基礎協議的主要協議是基於PoW一致性算法的區塊鏈。在PoW的狀況下，它是主要基礎中的本地寫協議的規範。成功找到PoW的nonce值做爲獨佔控件（領導者選擇算法）的礦工得到了將區塊添加爲主服務器的權利。可是，當有權成爲主服務器的節點同時出現時，區塊鏈會分叉。

另外一方面，採用2的重複寫協議的是基於PBFT的區塊鏈。包括Tendermint在內的各類基於PBFT的共識算法沒有主要服務器首先負責地執行每一個數據的更新，而且全部參與節點能夠在同一時段執行寫操做。也就是說，能夠說PBFT類型一致性協議相似於重複寫入類型的活動複製協議。

7–3.區塊鏈高可靠性通訊

我已經提到了區塊鏈的過程，但此次我將重點關注通訊連接。

在區塊鏈中，參與網絡的每一個節點執行P2P通訊並共享數據。另外，由領導者選擇算法選擇的主服務器執行多播，以便例如在找到隨機數時將新添加的 區塊的信息共享給每一個參與節點。此時，考慮到在通訊鏈路或節點中發生故障的狀況，重要的是實現原子多播，其是虛擬同步而且以總的順序執行消息傳遞。

那麼，區塊鏈中的原子多播問題和分佈式提交問題是如何解決的呢？

在採用比特幣等PoW的公共鏈中，原子多播還沒有實現。所以，可能會發生頻繁的叉子。因爲每一個節點隨時間正確地共享數據，所以創建了一致性，但確認交易存儲在區塊中須要10分鐘以上。

在這裏，咱們要關注Tendermint一致性算法。一般，存在2PC（兩階段提交）做爲實現原子提交的方法，而且已經提出了做爲改進版本的3PC方法，但二者都是不完整的。所以，Tendermint經過將區塊鏈與3PC方法混合並在循環方法下在節點上添加約束來實現原子提交。下一章將解釋這個創新分佈式提交問題的方法。

7–4.Tendermint中的分佈式提交（創新的三階段提交模型）

首先，Tendermint是PBFT類型。在Hyperledger中，做爲領導者的驗證者始終是相同的過程，可是Tendermint具備領導者選擇算法，而且經過循環法肯定性地肯定領導者。領導者共同提出存儲在mempool中的下一個交易塊。有了這個提議，Tendermint共識實現了3PC（三階段提交）並實現了原子組播。Tendermint一致性算法能夠大體分爲三種狀態。

1. PROPOSE

經過基於樁數的領導者選擇算法經過循環法肯定性地選擇的驗證器集的提議。在這種狀態下開始投票。

1. PRE-VOTE

擬議區塊的第一次投票。一旦得到三分之二或更多的批准，咱們將繼續進行下一步，但要等到收集全部選票的限制時間。因爲這個時間限制，能夠說Tendermint是部分異步一致性算法。此外，該投票算法具備1/3k的容錯能力。

1. PRE-COMMIT

在預投票中超過2/3的贊成第二次投票。此時，以下所述，當未收集2/3或更多的投票時，Tendermint的智能部分是一種衡量標準。

如前所述，經過爲三階段提交設置PRECOMMIT階段，若是知足如下條件，則能夠實現阻塞協議。

1. 沒有直接轉換爲COMMIT狀態或ABORT狀態的狀態
2. 沒有可能作出最終決定，也沒有轉換到COMMIT狀態的狀態。

在Tendermint中，在第二個投票階段投票的驗證者Pre-Commit被鎖定，而且只能在預投票中投票得到超過2/3票數的鎖定區塊或區塊。經過鎖定處理，知足上述兩個條件。換句話說，因爲每一個驗證器始終只能在預先提交中對一個塊進行投票，所以它不會實現分叉機制。

換句話說，「Tendermint共識是確保添加區塊的操做在網絡中的全部節點上完成，或者根本沒有節點完成;實現最終結果的下一代共識協議。