Fabric共識排序
排序服務在超級賬本 Fabric 網絡中起到十分核心的作用。所有交易在發送給 Committer 進行驗證接受之前，需要先經過排序服務進行全局排序。
在目前架構中，排序服務的功能被抽取出來，作爲單獨的 fabric-orderer 模塊來實現，代碼主要在 fabric/orderer 目錄下。
orderer service的實現有一下幾種，但是無論是哪一種共識，都不會產生分叉，因爲進行打包區塊的操作，是由固定的order節點進行操作的，同一時刻只有一個order節點在進行打包區塊，而比特幣因爲存在同一時刻，有兩個節點同時計算出hash值的概率，所以存在分叉，在fabric打包區塊的設置中，觸發打包區塊有兩個參數尤爲重要，一個爲batchsize，此參數是用於控制每個區塊裏可以存儲的數據的條數，當達到這一配置的時候自動打包成一個區塊，還有一個是timeout，當收到第一條數據達到這個時間的時候就會打包區塊，那麼在此timeout時間內的數據會同時打包到區塊中。
-
solo 模式
單節點此種方式使用於測試開發環境，因爲此種方式無法提高系統的吞吐量，同時無法與order節點之間進行容錯。 -
kafka模式
kafka也是一種cft容錯的一種基於zk實現leader-folower模式。kafka半去中心化。 -
raft模式
raft模式基於raft協議實現的共識算法，打包區塊有leader節點進行。
下面以 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 分區，通過共識算法來確保寫入到分區後的消息的一致性。即一旦寫入分區，任何 Orderer 節點看到的都是相同的消息隊列。
- Orderer節點在啓動後，還默認對本地賬本對應的 Kafka 分區數據進行監聽，不斷從 Kafka 拉取（Consume）新的交易消息，並對消息進行處理。滿足一定策略情況下（收到 TTX-C 或配置消息）還會將消息打包爲區塊。
KAFKA可以支持崩潰容錯，但無法對抗惡意攻擊。
