Hyperledger 源碼分析之 Fabric

排序服務在超級賬本 Fabric 網絡中起到十分核心的作用。所有交易在發送給 Committer 進行驗證接受之前，需要先經過排序服務進行全局排序。

在目前架構中，排序服務的功能被抽取出來，作為單獨的 fabric-orderer 模塊來實現，代碼主要在?fabric/orderer?目錄下。

下面以 Kafka 作為共識插件為例，講解 Orderer 節點的核心過程。

工作原理

Orderer 節點（Ordering Service Node，OSN）在網絡中起到代理作用，多個 Orderer 節點會連接到 Kafka 集群，利用 Kafka 的共識功能，完成對網絡中交易的排序和打包成區塊的工作。

Fabric 網絡提供了多通道特性，為了支持這一特性，同時保障每個 Orderer 節點上數據的一致性，排序服務進行了一些特殊設計。

對于每個通道，Orderer 將其映射到 Kafka 集群中的一個 topic （topic 名稱與 channelID 相同）上。由于 Orderer 目前并沒有使用 Kafka Topic 的多分區負載均衡特性，默認每個 topic 只創建了一個分區（0 號分區）。

此外，Orderer 還在本地維護了針對每個通道的賬本（區塊鏈）結構，其中每個區塊包括了一組排序后的交易消息，并且被分割為獨立區塊。

核心過程

核心過程如下所示。

• 客戶端通過 gRPC 連接發送交易信息到 Orderer 節點的?Broadcast()?接口。
• Orderer 節點收到請求后，提取消息進行解析、檢查，通過檢查后封裝為 Kafka 消息，通過 Produce 接口發送到 Kakfa 集群對應的 topic 分區中。當前消息數達到?BatchSize.MaxMessageCount?或消息尺寸過大，或超時時間達到?BatchTimeout，則發送分塊消息 TTC-X 到 Kafka。
• Kafka 集群維護多個 topic 分區。Kakfa 通過共識算法來確保寫入到分區后的消息的一致性。即一旦寫入分區，任何 Orderer 節點看到的都是相同的消息隊列。
• Orderer 節點在啟動后，還默認對本地賬本對應的 Kafka 分區數據進行監聽，不斷從 Kafka 拉取（Consume）新的交易消息，并對消息進行處理。滿足一定策略情況下（收到 TTX-C 或配置消息）還會將消息打包為區塊。

分塊決策

收到分塊消息 TTC-X，或收到配置交易，則切分消息為區塊。

轉載來自：https://blog.csdn.net/yeasy/article/details/78798506

總結

以上是生活随笔為你收集整理的Hyperledger Fabric 排序服务核心原理和工作过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。