交易必須按照發生的順序寫入分類帳，儘管它們可能位於網路中不同的參與者組之間。為了實現這一點，必須建立交易的順序，並且必須建立一種拒絕錯誤（或惡意）插入分類帳的壞交易的方法。

在分散式分類帳技術中，共識漸漸已成為單一功能中特定演算法的代名詞。然而，共識不僅僅是簡單地同意交易順序，而是通過在整個交易流程中的基本作用，從提案和認可到訂購，驗證和承諾，在Hyperledger Fabric中強調了這種差異化。簡而言之，共識被定義為對包含塊的一組交易的正確性的全面驗證。

Hyperledger Fabric共識機制，目前包括SOLO，Kafka，以及未來可能要使用的PBFT（實踐拜占庭容錯）、SBFT（簡化拜占庭容錯）

Solo

SOLO機制是一個非常容易部署的非生產環境的共識排序節點。它由一個為所有客戶服務的單一節點組成，所以不需要“共識”，因為只有一箇中央權威機構。相應地沒有高可用性或可擴充套件性。這使得獨立開發和測試很理想，但不適合生產環境部署。orderer-solo模式作為單節點通訊模式，所有從peer收到的訊息都在本節點進行排序與生成資料塊。

客戶端通過GRPC發起通訊，與Orderer連線成功之後，便可以向Orderer傳送訊息。Orderer通過Recv介面接收Peer傳送過來的訊息，Orderer將接收到的訊息生成資料塊，並將資料塊存入ledger，peer通過deliver介面從orderer中的ledger獲取資料塊

2.Kafka

Katka是一個分散式訊息系統，由LinkedIn使用scala編寫，用作LinkedIn的活動流（Activitystream)和運營資料處理管道（Pipeline）的基礎。具有高水平擴充套件和高吞吐量。

在Fabric網路中，資料是由Peer節點提交到Orderer排序服務，而Orderer相對於Kafka來說相當於上游模組，且Orderer還兼具提供了對資料進行排序及生成符合配置規範及要求的區塊。而使用上游模組的資料計算、統計、分析，這個時候就可以使用類似於Kafka這樣的分散式訊息系統來協助業務流程。

有人說Kafka是一種共識模式，也就是說平等信任，所有的HyperLedger Fabric網路加盟方都是可信方，因為訊息總是均勻地分佈在各處。但具體生產使用的時候是依賴於背書來做到確權，相對而言，Kafka應該只能是一種啟動Fabric網路的模式或型別。

Zookeeper一種在分散式系統中被廣泛用來作為分散式狀態管理、分散式協調管理、分散式配置管理和分散式鎖服務的叢集。Kafka增加和減少伺服器都會在Zookeeper節點上觸發相應的事件，Kafka系統會捕獲這些事件，進行新一輪的負載均衡，客戶端也會捕獲這些事件來進行新一輪的處理。

Orderer排序服務是Fablic網路事務流中的最重要的環節，也是所有請求的點，它並不會立刻對請求給予回饋，一是因為生成區塊的條件所限，二是因為依託下游叢集的訊息處理需要等待結果