Fabric Kafka入門

Hyperledger Fabric推薦Kafka用於生產環境。Kafka是一個分佈式、具備水平伸縮能力、崩潰容錯能力的日誌系統。在Hyperledger Fabric區塊鏈中能夠有多個Kafka節點，使用zookeeper進行同步管理。本文將介紹Kfaka的基本工做原理，以及在HyperledgerFabric中使用Kafka和zookeeper實現共識的原理，並經過一個實例剖析Hyperledger Farbic中Kafka共識的達成過程。

若是但願快速掌握Fabric區塊鏈的鏈碼及應用開發，建議訪問匯智網的在線互動課程：

• Fabric區塊鏈Java開發詳解
• Fabric區塊鏈NodeJs開發詳解

1、Kafka工做原理

Kafka本質上是一個消息處理系統，它使用的是經典的發佈-訂閱模型。消息的消費者訂閱特定的主題，以便收到新消息的通知，生產者則負責消息的發佈。

當主題的數據規模變得愈來愈大時，能夠拆分爲多個分區，Kafka保障在一個分區內的消息是按順序排列的。

Kafka並不跟蹤消費者讀取了哪些消息，也不會自動刪除已經讀取的消息。Kafka會保存消息一段時間，例如一天，或者直到數據規模超過必定的閾值。消費者須要輪詢新的消息，這是的他們能夠根據本身的需求來定位消息，所以能夠重放或從新處理事件。消費者處於不一樣的消費者分組，對應一個或多個消費者進程。每一個分區被分貝給單一的消費者進程，所以一樣的消息不會被屢次讀取。

崩潰容錯機制是經過在多個Kafka代理之間複製分區來實現的。所以若是一個代理因爲軟件或硬件故障掛掉，數據也不會丟失。固然接下來還須要一個領導-跟隨機制，領導者持有分區，跟隨者則進行分區的複製。當領導者掛掉後，會有某個跟隨者轉變爲新的領導者。

若是一個消費者訂閱了某個主體，那麼它怎麼知道從哪一個分區領導者來讀取訂閱的消息？

答案在於zookeeper服務。

zookeeper是一個分佈式key-value存儲庫，一般用於存儲元數據及集羣機制的實現。zookeeper容許服務（Kafka代理）的客戶端訂閱變化並得到實時通知。這就是代理如何肯定應當使用哪一個分區領導者的緣由。zookeeper有超強的故障容錯能力，所以Kafka的運行嚴重依賴於它。

在zookeeper中存儲的元數據包括：

• 消費者分組在每一個分區的讀取偏移量
• 訪問控制清單，用於訪問受權與限制
• 生產者及消費者配額，每秒最多消息數量
• 分區領導者及健康信息

2、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返回客戶端
• 當發生崩潰時，能夠利用不一樣的排序節點分發區塊，由於全部的排序節點都維護有本地日誌

3、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共識模塊是能夠用於生產環境的，它能夠支持崩潰容錯，但沒法對抗惡意攻擊。

---

原文：The ABCs of Kafka in Hyperledger Fabric