這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)Fabric區(qū)塊鏈kafka共識怎么理解，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
為淮上等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及淮上網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都做網(wǎng)站、網(wǎng)站設(shè)計(jì)、外貿(mào)營銷網(wǎng)站建設(shè)、淮上網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
Hyperledger Fabric推薦Kafa用于生產(chǎn)環(huán)境。Kafa是一個分布式、具有水平伸縮能力、崩潰容錯能力 的日志系統(tǒng)。在Hyperledger Fabric區(qū)塊鏈中可以有多個Kafka節(jié)點(diǎn)，使用zookeeper進(jìn)行同步管理。下面將介紹Kfaka的基本工作原理，以及在Hyperledger Fabric中使用Kafka和zookeeper實(shí)現(xiàn)共識的原理，并通過一個實(shí)例剖析Hyperledger Farbic中Kafka共識的達(dá)成過程。
Kafka本質(zhì)上是一個消息處理系統(tǒng)，它使用的是經(jīng)典的發(fā)布-訂閱模型。消息的消費(fèi)者訂閱特定的主題，以便收到新消息的通知，生產(chǎn)者則負(fù)責(zé)消息的發(fā)布。
當(dāng)主題的數(shù)據(jù)規(guī)模變得越來越大時(shí)，可以拆分為多個分區(qū)，Kafka保障在一個分區(qū)內(nèi)的消息是按順序排列的。
Kafka并不跟蹤消費(fèi)者讀取了哪些消息，也不會自動刪除已經(jīng)讀取的消息。Kafka會保存消息一段時(shí)間，例如一天，或者直到數(shù)據(jù)規(guī)模超過一定的閾值。消費(fèi)者需要輪詢新的消息，這使得他們可以根據(jù)自己的需求來定位消息，因此可以重放或重新處理事件。消費(fèi)者處于不同的消費(fèi)者分組，對應(yīng)一個或多個消費(fèi)者進(jìn)程。每個分區(qū)被分貝給單一的消費(fèi)者進(jìn)程，因此同樣的消息不會被多次讀取。
崩潰容錯機(jī)制是通過在多個Kafka代理之間復(fù)制分區(qū)來實(shí)現(xiàn)的。因此如果一個代理由于軟件或硬件故障掛掉，數(shù)據(jù)也不會丟失。當(dāng)然接下來還需要一個領(lǐng)導(dǎo)-跟隨機(jī)制，領(lǐng)導(dǎo)者持有分區(qū)，跟隨者則進(jìn)行分區(qū)的復(fù)制。當(dāng)領(lǐng)導(dǎo)者掛掉后，會有某個跟隨者轉(zhuǎn)變?yōu)樾碌念I(lǐng)導(dǎo)者。
如果一個消費(fèi)者訂閱了某個主體，那么它怎么知道從哪個分區(qū)領(lǐng)導(dǎo)者來讀取訂閱的消息？
答案在于zookeeper服務(wù)。
zookeeper是一個分布式key-value存儲庫，通常用于存儲元數(shù)據(jù)及集群機(jī)制的實(shí)現(xiàn)。zookeeper允許服務(wù)（Kafka代理）的客戶端訂閱變化并獲得實(shí)時(shí)通知。這就是代理如何確定應(yīng)當(dāng)使用哪個分區(qū)領(lǐng)導(dǎo)者的原因。zookeeper有超強(qiáng)的故障容錯能力，因此Kafka的運(yùn)行嚴(yán)重依賴于它。
在zookeeper中存儲的元數(shù)據(jù)包括：
消費(fèi)者分組在每個分區(qū)的讀取偏移量
訪問控制清單，用于訪問授權(quán)與限制
生產(chǎn)者及消費(fèi)者配額，每秒最多消息數(shù)量
分區(qū)領(lǐng)導(dǎo)者及健康信息
要理解在超級賬本Hyperledger Fabric中的Kafka是如何工作的，首先需要理解幾個重要的術(shù)語：
Chain - 指的是一組客戶端（通道/channel）可以訪問的日志
Channel - 一個通道類似于一個主題，授權(quán)的對等節(jié)點(diǎn)（peer）可以訂閱并且成為通道的成員。 只有通道的成員可以在通道上交易，一個通道中的交易在其他通道中看不到
OSN - 即排序服務(wù)節(jié)點(diǎn)（Ordering Service Node），在Fabric中被稱為排序節(jié)點(diǎn)。排序節(jié)點(diǎn)負(fù)責(zé)：
進(jìn)行客戶鑒權(quán)
允許客戶端通過一個簡單的接口寫入或讀取通道
執(zhí)行配置交易的過濾與驗(yàn)證，實(shí)現(xiàn)通道的重新配置或創(chuàng)建新的通道
RPC - 即遠(yuǎn)程過程調(diào)用（Remote Procedure Call），是一種用于調(diào)用其他機(jī)器上的服務(wù)而無需了解 通信與實(shí)現(xiàn)細(xì)節(jié)的通信協(xié)議，目的是像調(diào)用本地函數(shù)一樣調(diào)用網(wǎng)絡(luò)中其他機(jī)器上的函數(shù)
廣播PRC - 交易提交調(diào)用，由排序節(jié)點(diǎn)執(zhí)行
分發(fā)RPC - 交易分發(fā)請求，當(dāng)交易由kafka代理處理后，分發(fā)給請求節(jié)點(diǎn)
注意，雖然在Hyperledger Fabric中Kafka被稱為共識（Consensus），但是其核心是交易排序服務(wù)以及額外的崩潰容錯能力。
在Hyperledger Fabric中的Kafka實(shí)際運(yùn)行邏輯如下：
對于每一條鏈，都有一個對應(yīng)的分區(qū)
每個鏈對應(yīng)一個單一的分區(qū)主題
排序節(jié)點(diǎn)負(fù)責(zé)將來自特定鏈的交易（通過廣播RPC接收）中繼到對應(yīng)的分區(qū)
排序節(jié)點(diǎn)可以讀取分區(qū)并獲得在所有排序節(jié)點(diǎn)間達(dá)成一致的排序交易列表
一個鏈中的交易是定時(shí)分批處理的，也就是說當(dāng)一個新的批次的第一個交易進(jìn)來時(shí)，開始計(jì)時(shí)
當(dāng)交易達(dá)到最大數(shù)量時(shí)或超時(shí)后進(jìn)行批次切分，生成新的區(qū)塊
定時(shí)交易是另一個交易，由上面描述的定時(shí)器生成
每個排序節(jié)點(diǎn)為每個鏈維護(hù)一個本地日志，生成的區(qū)塊保存在本地賬本中
交易區(qū)塊通過分發(fā)RPC返回客戶端
當(dāng)發(fā)生崩潰時(shí)，可以利用不同的排序節(jié)點(diǎn)分發(fā)區(qū)塊，因?yàn)樗械呐判蚬?jié)點(diǎn)都維護(hù)有本地日志
考慮下圖，假設(shè)排序節(jié)點(diǎn)OSN0和OSN2時(shí)連接到廣播客戶端，OSN1連接到分發(fā)客戶端。
OSN0已經(jīng)有了交易foo，中繼到kafka集群
此時(shí)OSN2將交易baz廣播到集群中
最后，交易bar由OSN0發(fā)送到集群中
集群現(xiàn)在有三個交易，可以在圖中看到三個交易的在日志中的位置偏移量
客戶端發(fā)送分發(fā)請求，在OSN1的本地日志中，上述三個交易在4#區(qū)塊里。
因此OSN1將4#區(qū)塊返回客戶端，處理結(jié)束
Kakfa的高性能對于Hyperledger Fabric有很大的幫助，多個排序節(jié)點(diǎn)通過Kafka實(shí)現(xiàn)同步，而Kafka本身并不是排序節(jié)點(diǎn)，它只是將排序節(jié)點(diǎn)通過流連接起來。雖然Kafka支持崩潰容錯，它并不能提供對網(wǎng)絡(luò)中惡意攻擊的保護(hù)。需要一種拜占庭容錯方案（BFT）才可以對抗惡意的攻擊，但是目前Hyperledger Farbic框架中還有待實(shí)現(xiàn)這一機(jī)制。
總而言之，在Hyperledger Farbic中，Kafka共識模塊是可以用于生產(chǎn)環(huán)境的，它可以支持崩潰容錯， 但無法對抗惡意攻擊。
上述就是小編為大家分享的Fabric區(qū)塊鏈kafka共識怎么理解了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
重慶分公司
重慶分公司
