Hyperledger Fabric推薦Kafa用于生産環境。Kafa是一個分布式、具有水準伸縮能力、崩潰容錯能力
的日志系統。在Hyperledger Fabric區塊鍊中可以有多個Kafka節點，使用zookeeper進行同步管理。
本文将介紹Kfaka的基本工作原理，以及在Hyperledger Fabric中使用Kafka和zookeeper實作共識的原理，并通過一個執行個體剖析Hyperledger Farbic中Kafka共識的達成過程。
如果希望快速掌握Fabric區塊鍊的鍊碼及應用開發，建議通路彙智網的線上互動課程：
- Fabric區塊鍊Java開發詳解
- Fabric區塊鍊NodeJs開發詳解
一、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共識子產品是可以用于生産環境的，它可以支援崩潰容錯，
但無法對抗惡意攻擊。
原文：Fabric Kafka入門 — 彙智網