Hyperledger Fabric推薦Kafka用於生產環境。Kafka是一個分佈式、具有水平伸縮能力、崩潰容錯能力的日誌系統。在Hyperledger Fabric區塊鏈中可以有多個Kafka節點，使用zookeeper進行同步管理。本文將介紹Kfaka的基本工作原理，以及在HyperledgerFabric中使用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）纔可以對抗惡意的攻擊，但是目前在Farbic框架中還有待實現這一機制。
總而言之，在Hyperledger Farbic中，Kafka共識模塊是可以用於生產環境的，它可以支持崩潰容錯，但無法對抗惡意攻擊。