菜鳥系列Fabric——Fabric 1.4共識機制(5)

fabric 共識機制

由於fabric是分布式的系統，因此需要共識機制來保障各個節點以相同的順序狀態保存賬本，達成一致性。 在當前fabric1.4版本中，存在三種共識機制，分別是solo，kafka，etcdraft。交易的共識包括3個階段的處理：提議階段、打包階段和驗證階段。

1.Solo 共識模式

Solo共識模式指網絡環境中只有一個排序節點，從Peer節點發送來的消息由一個排序節點進行排序和產生區塊；由於排序服務只有一個排序節點為所有Peer節點服務，沒有高可用性和可擴展性，不適合用於生產環境，通常用於開發和測試環境。

Solo共識模式調用過程說明：

1. Peer節點通過gPRC連接排序服務，連接成功后，發送交易信息。
2. 排序服務通過Recv接口，監聽Peer節點發送過來的信息，收到信息后進行數據區塊處理。
3. 排序服務根據收到的消息生成數據區塊，並將數據區塊寫入賬本（Ledger）中，返回處理信息。
4. Peer節點通過deliver接口，獲取排序服務生成的區塊數據。

2.Kafka 共識模式

Hyperledger Fabric的核心共識算法通過Kafka集群實現，簡單來說，就是通過Kafka對所有交易信息進行排序（如果系統存在多個channel，則對每個channel分別排序）。
Kafka是一個分布式的流式信息處理平台，目標是為實時數據提供統一的、高吞吐、低延遲的性能。
Kafka由以下幾類角色構成：

• Broker：消息處理節點，主要任務是接收producers發送的消息，然后寫入對應的topic的partition中，並將排序后的消息發送給訂閱該topic的consumers。 大量的Broker節點提高了數據吞吐量，並互相對partition數據做冗余備份（類似RAID技術）。
• Zookeeper：為Brokers提供集群管理服務和共識算法服務（paxos算法），例如，選舉leader節點處理消息並將結果同步給其它followers節點，移除故障節點以及加入新節點並將最新的網絡拓撲圖同步發送給所有Brokers。
• Producer：消息生產者，應用程序通過調用Producer API將消息發送給Brokers。
• Consumer：消息消費者，應用程序通過Consumer API訂閱topic並接收處理后的消息。

Kafka將消息分類保存為多個topic，每個topic中包含多個partition，消息被連續追加寫入partition中，形成目錄式的結構。一個topic可以被多個consumers訂閱。簡單來說，partition就是一個FIFO的消息管道，一端由producer寫入消息，另一端由consumer取走消息（注意，這里的取走並不會移除消息，而是移動consumer的位置指針）。

在Hyperledger Fabric中的Kafka實際運行邏輯如下：

1. 對於每一條鏈，都有一個對應的分區
2. 每個鏈對應一個單一的分區主題
3. 排序節點負責將來自特定鏈的交易（通過廣播RPC接收）中繼到對應的分區
4. 排序節點可以讀取分區並獲得在所有排序節點間達成一致的排序交易列表
5. 一個鏈中的交易是定時分批處理的，也就是說當一個新的批次的第一個交易進來時，開始計時
6. 當交易達到最大數量時或超時后進行批次切分，生成新的區塊
7. 定時交易是另一個交易，由上面描述的定時器生成
8. 每個排序節點為每個鏈維護一個本地日志，生成的區塊保存在本地賬本中
9. 交易區塊通過分發RPC返回客戶端
10. 當發生崩潰時，可以利用不同的排序節點分發區塊，因為所有的排序節點都維護有本地日志

3. Etcdraft 共識模式

Raft 是 v1.4.1 中引入的，它是一種基於 etcd 的崩潰容錯（CFT）排序服務。Raft 遵循 “領導者和追隨者” 模型，其中領導者在通道中的orderer節點之間動態選出（這個節點集合稱為“consenter set”），該領導者將消息復制到跟隨者節點。由於系統可以承受節點（包括領導節點）的丟失，只要剩下大多數排序節點（即所謂的“仲裁”），Raft就被稱為“崩潰容錯”（CFT）。換句話說，如果一個通道中有三個節點，它可以承受一個節點的丟失（剩下兩個節點）。

3.1 raft相關概念

• 日志條目：Raft排序服務中的主要工作單元是“日志條目”，這些條目的完整序列稱為“日志”。如果成員的多數（法定人數，換言之）成員到條目及其順序達成一致，我們認為日志是一致的。

• Consenter設置：排序節點主動參與給定信道的共識機制並接收信道的復制日志。這可以是所有可用節點（在單個群集中或在對系統通道有貢獻的多個群集中），或者是這些節點的子集。

• 有限狀態機（FSM）：Raft中的每個排序節點都有一個FSM，它們共同用於確保各個排序節點中的日志序列是確定性的（以相同的順序編寫）。

• 法定人數：描述需要確認提案的最少數量的同意者，以便可以提交交易。對於每個consenter集，這是 大多數節點。在具有五個節點的群集中，必須有三個節點才能存在仲裁。如果由於任何原因導致法定數量的節點不可用，則orderer將無法用於通道上的讀取和寫入操作，並且不能提交新日志。

• Leader：Leader負責提取新的日志條目，將它們復制到跟隨者訂購節點，以及管理何時認為條目已提交。這不是特殊類型orderer人。在情況決定的情況下，這只是orderer在某些時候可能擁有的角色，而不是其他角色。

• Follower：Follower從Leader那里接收日志並確定性地復制它們，確保日志保持一致。Follower也會收到來自Leader的“心跳”信息。如果Leader停止在可配置的時間內發送這些消息，則追將發起選舉，其中一個Follower將被選為新Leader。

3.2 raft在交易中的流程

每個通道都在Raft協議的單獨實例上運行，這允許每個實例選擇不同的leader。還允許集群由不同組織控制的排序節點組成的用例中進一步分散服務。雖然所有Raft節點必須是系統通道的一部分，但它們不一定必須是所有應用程序通道的一部分。通道創建者（和通道管理員）可以選擇可用orderer的子集，並根據需要添加或刪除orderer（一次只能添加或刪除一個節點）。

在Raft中，交易（提案或配置更新的形式）由接收交易的orderer節點自動路由到該信道的當前leader。這意味着peer和應用程序不需要知道leader是誰。只有orderer節點需要知道。

3.3 raft節點選舉日志傳輸

raft節點始終處於以下三種狀態之一：follower，candidate或leader。所有節點最初都是follower。在這種狀態下，他們可以接受來自leader的日志條目（如果已經當選），或者為leader投票。如果在設定的時間內沒有收到日志條目或心跳（例如，五秒），則節點會自我提升到candidate狀態。在候選狀態中，節點請求來自其他節點的投票。如果候選人獲得法定數量的選票，則將其提升為leader。leader接受新的日志條目並將其復制給follower。

雖然可以無限期地保留所有日志，但為了節省磁盤空間，Raft使用一個名為“snapshotting”的進程，用戶可以在其中定義將在日志中保留多少字節的數據。每個快照將包含一定數量的塊）。

有興趣的關注IT程序員客棧哦