Fabric區塊鏈kafka共識入門
Hyperledger Fabric推薦Kafa用於生產環境。Kafa是一個分散式、具有水平伸縮能力、崩潰容錯能力 的日誌系統。在Hyperledger Fabric區塊鏈中可以有多個Kafka節點，使用zookeeper進行同步管理。 本文將介紹Kfaka的基本工作原理，以及在Hyperledger Fabric中使用Kafka和zookeeper實現共識的原理，並通過一個例項剖析Hyperledger Farbic中Kafka共識的達成過程。
如果希望快速掌握Fabric區塊鏈的鏈碼及應用開發，建議訪問匯智網的線上互動課程：
一、Kafka工作原理
Kafka本質上是一個訊息處理系統，它使用的是經典的釋出-訂閱模型。訊息的消費者訂閱特定的主題，以便收到新訊息的通知，生產者則負責訊息的釋出。
當主題的資料規模變得越來越大時，可以拆分為多個分割槽，Kafka保障在一個分割槽內的訊息是按順序排列的。
Kafka並不跟蹤消費者讀取了哪些訊息，也不會自動刪除已經讀取的訊息。Kafka會儲存訊息一段時間，例如一天，或者直到資料規模超過一定的閾值。消費者需要輪詢新的訊息，這使得他們可以根據自己的需求來定位訊息，因此可以重放或重新處理事件。消費者處於不同的消費者分組，對應一個或多個消費者程序。每個分割槽被分貝給單一的消費者程序，因此同樣的訊息不會被多次讀取。
崩潰容錯機制是通過在多個Kafka代理之間複製分割槽來實現的。因此如果一個代理由於軟體或硬體故障掛掉，資料也不會丟失。當然接下來還需要一個領導-跟隨機制，領導者持有分割槽，跟隨者則進行分割槽的複製。當領導者掛掉後，會有某個跟隨者轉變為新的領導者。
如果一個消費者訂閱了某個主體，那麼它怎麼知道從哪個分割槽領導者來讀取訂閱的訊息？
答案在於zookeeper服務。
zookeeper是一個分散式key-value儲存庫，通常用於儲存元資料及叢集機制的實現。zookeeper允許服務（Kafka代理）的客戶端訂閱變化並獲得實時通知。這就是代理如何確定應當使用哪個分割槽領導者的原因。zookeeper有超強的故障容錯能力，因此Kafka的執行嚴重依賴於它。
在zookeeper中儲存的元資料包括：
- 消費者分組在每個分割槽的讀取偏移量
- 訪問控制清單，用於訪問授權與限制
- 生產者及消費者配額，每秒最多訊息數量
- 分割槽領導者及健康資訊
二、Hyperledger Fabric中的Kafka
要理解在超級賬本Hyperledger Fabric中的Kafka是如何工作的，首先需要理解幾個重要的術語：
- Chain - 指的是一組客戶端（通道/channel）可以訪問的日誌
- Channel - 一個通道類似於一個主題，授權的對等節點（peer）可以訂閱並且成為通道的成員。 只有通道的成員可以在通道上交易，一個通道中的交易在其他通道中看不到
- OSN - 即排序服務節點（Ordering Service Node），在Fabric中被稱為排序節點。排序節點負責：
- 進行客戶鑑權
- 允許客戶端通過一個簡單的介面寫入或讀取通道
- 執行配置交易的過濾與驗證，實現通道的重新配置或建立新的通道
- RPC - 即遠端過程呼叫（Remote Procedure Call），是一種用於呼叫其他機器上的服務而無需瞭解 通訊與實現細節的通訊協議，目的是像呼叫本地函式一樣呼叫網路中其他機器上的函式
- 廣播PRC - 交易提交呼叫，由排序節點執行
- 分發RPC - 交易分發請求，當交易由kafka代理處理後，分發給請求節點
注意，雖然在Hyperledger Fabric中Kafka被稱為共識（Consensus），但是其核心是交易排序服務以及額外的崩潰容錯能力。
在Hyperledger Fabric中的Kafka實際執行邏輯如下：
- 對於每一條鏈，都有一個對應的分割槽
- 每個鏈對應一個單一的分割槽主題
- 排序節點負責將來自特定鏈的交易（通過廣播RPC接收）中繼到對應的分割槽
- 排序節點可以讀取分割槽並獲得在所有排序節點間達成一致的排序交易列表
- 一個鏈中的交易是定時分批處理的，也就是說當一個新的批次的第一個交易進來時，開始計時
- 當交易達到最大數量時或超時後進行批次切分，生成新的區塊
- 定時交易是另一個交易，由上面描述的定時器生成
- 每個排序節點為每個鏈維護一個本地日誌，生成的區塊儲存在本地賬本中
- 交易區塊通過分發RPC返回客戶端
- 當發生崩潰時，可以利用不同的排序節點分發區塊，因為所有的排序節點都維護有本地日誌
三、Hyperledger Fabric Kafka例項解析
考慮下圖，假設排序節點OSN0和OSN2時連線到廣播客戶端，OSN1連線到分發客戶端。
- OSN0已經有了交易foo，中繼到kafka叢集
- 此時OSN2將交易baz廣播到叢集中
- 最後，交易bar由OSN0傳送到叢集中
- 叢集現在有三個交易，可以在圖中看到三個交易的在日誌中的位置偏移量
- 客戶端傳送分發請求，在OSN1的本地日誌中，上述三個交易在4#區塊裡。
- 因此OSN1將4#區塊返回客戶端，處理結束
Kakfa的高效能對於Hyperledger Fabric有很大的幫助，多個排序節點通過Kafka實現同步，而Kafka本身並不是排序節點，它只是將排序節點通過流連線起來。雖然Kafka支援崩潰容錯，它並不能提供對網路中惡意攻擊的保護。需要一種拜占庭容錯方案（BFT）才可以對抗惡意的攻擊，但是目前Hyperledger Farbic框架中還有待實現這一機制。
總而言之，在Hyperledger Farbic中，Kafka共識模組是可以用於生產環境的，它可以支援崩潰容錯， 但無法對抗惡意攻擊。