Fabric Orderer的共識算法是可插拔的，包括Solo、Kafka、Raft，其中Raft算法是在Fabric v1.4版本中新增的，未來還將加入BFT算法。本文會對已實現的3個共識算法進行剖析。
一、Solo
Solo算法中只有一個orderer節點，用於開發階段的實驗。一個Orderer節點不存在共識的問題，該節點接收所有來自客戶端的交易，然後將其排序併產生區塊，如下圖所示：
二、Kafka
所有的orderer都會連接kafka集羣，而orderer之間並沒有直接的連接，如下圖所示：
所有trasaction的排序依賴於kafka，kafka的partition裏面的數據均是按時間進行排序的，因此可以幫助Orderer集羣進行排序。
那麼基於kafka排序，是如何做到orderer集羣上的所有節點都產生相同區塊的？
- 以交易數量分割區塊是容易的，對任意的OSN來說，都會得到相同的區塊。
- 但是基於時間分割區塊，各個節點的時間是有偏差的，所以需要各個節點間明確的協調信號。
基於時間分割區塊的分析如下：
1、一個channel對應kafka中的一個topic，topic裏面使用單partition；
2、每個OSN在分割區塊之前都向Partition發出消息（是時候分割區塊X啦 TTC-X），直到接收到任意TTC-X消息進行分割區塊，不一定是自己發出的TTC-X消息，而是第一個TTC-X，其他的TTC-X會被忽略；
3、每個OSN在本地保存每個channel的區塊文件。Delivery請求現在只需要順序地讀取本地ledger，沒有冗餘數據，也沒有lookup表。OSN只需要保存最後讀取的偏移量，這樣在重聯之後就可以知道從哪裏開始重新消費Kafka的消息；
4、OSN返回的delivery響應包含orderer的簽名。
kafka共識的整體框架：
kafka共識的整體框架圖如下，OSN0和OSN2從client接收交易，然後發送到kafka集羣，kafka將3個交易進行排序，然後發送到所有OSN，OSN根據出塊規則將交易打包成區塊，然後將區塊發送給peer節點。
config sequence機制：
如果修改配置讓某一類transaction不再接收，設定其爲非法交易。這時需要提交一個config交易，要經過kafka共識，但是config交易和普通交易是被異步發送給kafka集羣的，所以不能保證config交易趕在非法的普通交易之前被共識。
從kafka接收到config交易後，要對剛纔異步過程中的普通交易進行重新校驗，過濾掉非法交易，防止漏判，所以需要用到config sequence機制。
所有transaction都有基於是config的sequence，當修改了config，sequence就會增加1，當收到transaction，發現不是基於最新的sequence，這些transaction就需要重新驗證，並且重新發送給kafka進行共識，以防在新config下本應是非法的交易被提交到賬本里。
三、Raft
Fabric orderer的Raft共識基於Etcd/raft庫，進一步封裝實現了出塊邏輯。
使用Raft取代kafka共識的原因：
- Raft共識與kafka並沒有本質的區別，但是不再需要依賴Kafka/Zookeeper了，kafka共識最少需要部署4個kafka節點和3個zookeeper節點，架構不夠簡潔，另外kafka的運維本身也比較複雜。實現Raft共識極大地簡化了運維工作。
- 基於Kafka共識，使得orderer之間沒有通信，做raft就會實現orderer的通訊層，以後做BFT這也是必須的，爲以後新共識算法做基礎，通訊層的實現也使得共識模塊的可插拔更加可用
Raft共識的實現：
- 每個channel都會運行自己的Raft實例，任何一個channel都是在所有orderer的子集裏進行運行，比如某個channel只有三個組織需要參與共識，那麼可以只把這三個組織的orderer加入到該channel裏，不需要其他orderer參與通訊；
- 所有的orderers都必須屬於system channel，否則新創建一個user channel，如果一個orderer不在system channel裏，就沒法拿到帶有“New channel”transaction的block，也就沒法知道有新的channel被創建，下圖中展現了system channel中各個orderer節點的通訊關係；
- orderer節點間通過TLS cert進行身份識別，配置channel時，會定義這個channel裏會有哪些orderer節點，所以需要TLS cert來實現身份認證。
Fabric v1.4.2開發了Kafka遷移到Raft的工具（kafka開發工作較少，所以之前用的kafka，將來會主推Raft，直到BFT出來爲止）
四、總結
- Kafka對transaction進行共識：
把transaction發送給kafka，從kafka獲取的是全排序後的transacton，然後由orderer節點自己切割區塊。 - Raft則是對block進行共識：
follower拿到transaction後轉發給leader，先由leader打包成塊，然後把區塊發送給follower進行共識。這與大部分區塊鏈項目一致。