Hyperledger Fabric推薦Kafa用于生產(chǎn)環(huán)境。Kafa是一個分布式、具有水平伸縮能力、崩潰容錯能力的日志系統(tǒng)。在Hyperledger Fabric區(qū)塊鏈中可以有多個Kafka節(jié)點，使用zookeeper進行同步管理。本文將介紹Kfaka的基本工作原理，以及在HyperledgerFabric中使用Kafka和zookeeper實現(xiàn)共識的原理，并通過一個實例剖析Hyperledger Farbic中Kafka共識的達成過程。

如果希望快速掌握Fabric區(qū)塊鏈的鏈碼及應(yīng)用開發(fā)，建議訪問匯智網(wǎng)的在線互動課程：

• Fabric區(qū)塊鏈Java開發(fā)詳解
• Fabric區(qū)塊鏈NodeJs開發(fā)詳解

一、Kafka工作原理

Kafka本質(zhì)上是一個消息處理系統(tǒng)，它使用的是經(jīng)典的發(fā)布-訂閱模型。消息的消費者訂閱特定的主題，以便收到新消息的通知，生產(chǎn)者則負責(zé)消息的發(fā)布。

當(dāng)主題的數(shù)據(jù)規(guī)模變得越來越大時，可以拆分為多個分區(qū)，Kafka保障在一個分區(qū)內(nèi)的消息是按順序排列的。

Kafka并不跟蹤消費者讀取了哪些消息，也不會自動刪除已經(jīng)讀取的消息。Kafka會保存消息一段時間，例如一天，或者直到數(shù)據(jù)規(guī)模超過一定的閾值。消費者需要輪詢新的消息，這是的他們可以根據(jù)自己的需求來定位消息，因此可以重放或重新處理事件。消費者處于不同的消費者分組，對應(yīng)一個或多個消費者進程。每個分區(qū)被分貝給單一的消費者進程，因此同樣的消息不會被多次讀取。

崩潰容錯機制是通過在多個Kafka代理之間復(fù)制分區(qū)來實現(xiàn)的。因此如果一個代理由于軟件或硬件故障掛掉，數(shù)據(jù)也不會丟失。當(dāng)然接下來還需要一個領(lǐng)導(dǎo)-跟隨機制，領(lǐng)導(dǎo)者持有分區(qū)，跟隨者則進行分區(qū)的復(fù)制。當(dāng)領(lǐng)導(dǎo)者掛掉后，會有某個跟隨者轉(zhuǎn)變?yōu)樾碌念I(lǐng)導(dǎo)者。

如果一個消費者訂閱了某個主體，那么它怎么知道從哪個分區(qū)領(lǐng)導(dǎo)者來讀取訂閱的消息？

答案在于zookeeper服務(wù)。

zookeeper是一個分布式key-value存儲庫，通常用于存儲元數(shù)據(jù)及集群機制的實現(xiàn)。zookeeper允許服務(wù)（Kafka代理）的客戶端訂閱變化并獲得實時通知。這就是代理如何確定應(yīng)當(dāng)使用哪個分區(qū)領(lǐng)導(dǎo)者的原因。zookeeper有超強的故障容錯能力，因此Kafka的運行嚴重依賴于它。

在zookeeper中存儲的元數(shù)據(jù)包括：

• 消費者分組在每個分區(qū)的讀取偏移量
• 訪問控制清單，用于訪問授權(quán)與限制
• 生產(chǎn)者及消費者配額，每秒最多消息數(shù)量
• 分區(qū)領(lǐng)導(dǎo)者及健康信息

二、Hyperledger Fabric中的Kafka

要理解在超級賬本Hyperledger Fabric中的Kafka是如何工作的，首先需要理解幾個重要的術(shù)語：

• Chain - 指的是一組客戶端（通道/channel）可以訪問的日志
• Channel - 一個通道類似于一個主題，授權(quán)的對等節(jié)點（peer）可以訂閱并且成為通道的成員。 只有通道的成員可以在通道上交易，一個通道中的交易在其他通道中看不到。
• OSN - 即排序服務(wù)節(jié)點（Ordering Service Node），在Fabric中被稱為排序節(jié)點。排序節(jié)點負責(zé)：
  • 進行客戶鑒權(quán)
  • 允許客戶端通過一個簡單的接口寫入或讀取通道
  • 執(zhí)行配置交易的過濾與驗證，實現(xiàn)通道的重新配置或創(chuàng)建新的通道
• RPC - 即遠程過程調(diào)用（Remote Procedure Call），是一種用于調(diào)用其他機器上的服務(wù)而無需了解 通信與實現(xiàn)細節(jié)的通信協(xié)議，目的是像調(diào)用本地函數(shù)一樣調(diào)用網(wǎng)絡(luò)中其他機器上的函數(shù)
• 廣播PRC - 交易提交調(diào)用，由排序節(jié)點執(zhí)行
• 分發(fā)RPC - 交易分發(fā)請求，當(dāng)交易由kafka代理處理后，分發(fā)給請求節(jié)點

注意，雖然在Hyperledger Fabric中Kafka被稱為共識（Consensus），但是其核心是交易排序服務(wù)以及額外的崩潰容錯能力。

在Hyperledger Fabric中的Kafka實際運行邏輯如下：

• 對于每一條鏈，都有一個對應(yīng)的分區(qū)
• 每個鏈對應(yīng)一個單一的分區(qū)主題
• 排序節(jié)點負責(zé)將來自特定鏈的交易（通過廣播RPC接收）中繼到對應(yīng)的分區(qū)
• 排序節(jié)點可以讀取分區(qū)并獲得在所有排序節(jié)點間達成一致的排序交易列表
• 一個鏈中的交易是定時分批處理的，也就是說當(dāng)一個新的批次的第一個交易進來時，開始計時
• 當(dāng)交易達到最大數(shù)量時或超時后進行批次切分，生成新的區(qū)塊
• 定時交易是另一個交易，由上面描述的定時器生成
• 每個排序節(jié)點為每個鏈維護一個本地日志，生成的區(qū)塊保存在本地賬本中
• 交易區(qū)塊通過分發(fā)RPC返回客戶端
• 當(dāng)發(fā)生崩潰時，可以利用不同的排序節(jié)點分發(fā)區(qū)塊，因為所有的排序節(jié)點都維護有本地日志

三、Hyperledger Fabric Kafka實例解析

考慮下圖，假設(shè)排序節(jié)點OSN0和OSN2時連接到廣播客戶端，OSN1連接到分發(fā)客戶端。

• OSN0已經(jīng)有了交易foo，中繼到kafka集群
• 此時OSN2將交易baz廣播到集群中
• 最后，交易bar由OSN0發(fā)送到集群中
• 集群現(xiàn)在有三個交易，可以在圖中看到三個交易的在日志中的位置偏移量
• 客戶端發(fā)送分發(fā)請求，在OSN1的本地日志中，上述三個交易在4#區(qū)塊里。
• 因此OSN1將4#區(qū)塊返回客戶端，處理結(jié)束

Kakfa的高性能對于Hyperledger Fabric有很大的幫助，多個排序節(jié)點通過Kafka實現(xiàn)同步，而Kafka本身并不是排序節(jié)點，它只是將排序節(jié)點通過流連接起來。雖然Kafka支持崩潰容錯，它并不能提供對網(wǎng)絡(luò)中惡意***的保護。需要一種拜占庭容錯方案（BFT）才可以對抗惡意的***，但是目前在Farbic框架中還有待實現(xiàn)這一機制。

總而言之，在Hyperledger Farbic中，Kafka共識模塊是可以用于生產(chǎn)環(huán)境的，它可以支持崩潰容錯，但無法對抗惡意***。

---

原文：The ABCs of Kafka in Hyperledger Fabric

轉(zhuǎn)載于:https://blog.51cto.com/xxzhi/2385962

總結(jié)

以上是生活随笔為你收集整理的Fabric Kafka入门的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。