菜鳥系列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」的進程，用戶能夠在其中定義將在日誌中保留多少字節的數據。每一個快照將包含必定數量的塊）。