Raft 共識算法概念
Raft 是一種基於 etcd 中 Raft 協議實現的崩潰容錯（Crash Fault Tolerant，CFT）排序服務。Raft 遵循“領導者跟隨者”模型，這個模型中，在每個通道上選舉領導者節點，其決策被跟隨者複製。Raft 排序服務會比基於 Kafka 的排序服務更容易設置和管理，它的設計允許不同的組織爲分佈式排序服務貢獻節點。
對於將用於生產網絡的排序服務，Fabric 實現了使用“領導者跟隨者”模型的 Raft 協議，領導者是在一個通道的排序節點中動態選擇的（這個集合的節點稱爲“共識者集合（consenter set）”），領導者將信息複製到跟隨者節點。Raft 被稱爲“崩潰容錯”是因爲系統可以承受節點的損失，包括領導者節點，前提是要剩餘大量的排序節點（稱爲“法定人數（quorum）”）。換句話說，如果一個通道中有三個節點，它可以承受一個節點的丟失（剩下兩個節點）。如果一個通道中有五個節點，則可以丟失兩個節點（剩下三個節點）。
Raft 是向開發拜占庭容錯（BFT）排序服務邁出的第一步。正如我們將看到的，Fabric 開發中的一些決策是由這個驅動的。如果你對 BFT 感興趣，學習如何使用 Raft 應該可以慢慢過渡。
Raft 概念
雖然 Raft 提供了許多與 Kafka 相同的功能（儘管它是一個簡單易用的軟件包）但它與 Kafka 的功能卻大不相同，它向 Fabric 引入了許多新的概念，或改變了現有的概念。
日誌條目（Log entry）。 Raft 排序服務中的主要工作單元是一個“日誌條目”，該項的完整序列稱爲“日誌”。如果大多數成員（換句話說是一個法定人數）同意條目及其順序，則我們認爲條目是一致的，然後將日誌複製到不同排序節點上。
共識者集合（Consenter set）。主動參與給定通道的共識機制並接收該通道的日誌副本的排序節點。這可以是所有可用的節點（在單個集羣中或在多個集羣中爲系統通道提供服務），也可以是這些節點的一個子集。
有限狀態機（Finite-State Machine，FSM）。Raft 中的每個排序節點都有一個 FSM，它們共同用於確保各個排序節點中的日誌序列是確定（以相同的順序編寫）。
法定人數（Quorum）。描述需要確認提案的最小同意人數。對於每個共識者集合，這是大多數節點。在具有五個節點的集羣中，必須有三個節點可用，纔能有一個法定人數。如果節點的法定人數因任何原因不可用，則排序服務集羣對於通道上的讀和寫操作都不可用，並且不能提交任何新日誌。
領導者（Leader）。這並不是一個新概念，正如我們所說，Kafka 也使用了領導者，但是在任何給定的時間，通道的共識者集合都選擇一個節點作爲領導者，這一點非常重要（我們稍後將在 Raft 中描述這是如何發生的）。領導者負責接收新的日誌條目，將它們複製到跟隨者的排序節點，並在認爲提交了某個條目時進行管理。這不是一種特殊類型的排序節點。它只是排序節點在某些時候可能扮演的角色，而不是由客觀環境決定的其他角色。
跟隨者（Follower）。再次強調，這不是一個新概念，但是理解跟隨者的關鍵是跟隨者從領導者那裏接收日誌並複製它們，確保日誌保持一致。我們將在關於領導者選舉的部分中看到，跟隨者也會收到來自領導者的“心跳”消息。如果領導者在一段可配置的時間內停止發送這些消息，跟隨者將發起一次領導者選舉，它們中的一個將當選爲新的領導者。
交易流程中的 Raft
每個通道都在 Raft 協議的單獨實例上運行，該協議允許每個實例選擇不同的領導者。這種配置還允許在集羣由不同組織控制的排序節點組成的用例中進一步分散服務。雖然所有 Raft 節點都必須是系統通道的一部分，但它們不一定必須是所有應用程序通道的一部分。通道創建者（和通道管理員）能夠選擇可用排序節點的子集，並根據需要添加或刪除排序節點（只要一次只添加或刪除一個節點）。
雖然這種配置以冗餘心跳消息和線程的形式產生了更多的開銷，但它爲 BFT 奠定了必要的基礎。
在 Raft 中，交易（以提案或配置更新的形式）由接收交易的排序節點自動路由到該通道的當前領導者。這意味着 Peer 節點和應用程序在任何特定時間都不需要知道誰是領導者節點。只有排序節點需要知道。
當排序節點檢查完成後，將按照我們交易流程的第二階段的描述，對交易進行排序、打包成區塊、協商並分發。
Raft 是如何選舉領導者的
節點總是處於以下三種狀態之一：跟隨者、候選人或領導者。所有節點最初都是作爲跟隨者開始的。在這種狀態下，他們可以接受來自領導者的日誌條目（如果其中一個已經當選），或者爲領導者投票。如果在一段時間內沒有接收到日誌條目或心跳（例如，5秒），節點將自己提升到候選狀態。在候選狀態中，節點從其他節點請求選票。如果候選人獲得法定人數的選票，那麼他就被提升爲領導者。領導者必須接受新的日誌條目並將其複製到跟隨者。
快照
如果一個排序節點宕機，它如何在重新啓動時獲得它丟失的日誌？
雖然可以無限期地保留所有日誌，但是爲了節省磁盤空間，Raft 使用了一個稱爲“快照”的過程，在這個過程中，用戶可以定義日誌中要保留多少字節的數據。這個數據量將決定區塊的數量（這取決於區塊中的數據量。注意，快照中只存儲完整的區塊）。
例如，假設滯後副本 R1 剛剛重新連接到網絡。它最新的區塊是100。領導者 L 位於第 196 塊，並被配置爲快照20個區塊。R1 因此將從 L 接收區塊 180，然後爲區塊 101 到 180 區塊 分發 請求。然後180 到 196 的區塊將通過正常 Raft 協議複製到 R1。