raft演算法由史丹福大學的diego ongaro和john ousterhout於2023年在**《in search of anunderstandable consensus algorithm》中提出。raft演算法面向對多個決策達成一致的問題，分解了leader選舉、日誌複製和安全方面的考慮，並通過約束減少了不確定性的狀態空間。
同步日誌：leader會找到系統中日誌最新的記錄，並強制所有的follower來重新整理到這個記錄，資料的同步是單向的。
日誌條目（log entry）。 raft 排序服務中的主要工作單元是乙個「日誌條目」，該項的完整序列稱為「日誌」。如果大多數成員（換句話說是乙個法定人數）同意條目及其順序，則我們認為條目是一致的，然後將日誌複製到不同排序節點上。
共識者集合（consenter set）。主動參與給定通道的共識機制並接收該通道的日誌副本的排序節點。這可以是所有可用的節點（在單個集群中或在多個集群中為系統通道提供服務），也可以是這些節點的乙個子集。
有限狀態機（finite-state machine，fsm）。raft 中的每個排序節點都有乙個 fsm，它們共同用於確保各個排序節點中的日誌序列是確定（以相同的順序編寫）。
法定人數（quorum）。描述需要確認提案的最小同意人數。對於每個共識者集合，這是大多數節點。在具有五個節點的集群中，必須有三個節點可用，才能有乙個法定人數。如果節點的法定人數因任何原因不可用，則排序服務集群對於通道上的讀和寫操作都不可用，並且不能提交任何新日誌。
領導者（leader）。這並不是乙個新概念，正如我們所說，kafka 也使用了領導者，但是在任何給定的時間，通道的共識者集合都選擇乙個節點作為領導者，這一點非常重要（我們稍後將在 raft 中描述這是如何發生的）。領導者負責接收新的日誌條目，將它們複製到跟隨者的排序節點，並在認為提交了某個條目時進行管理。這不是一種特殊型別的排序節點。它只是排序節點在某些時候可能扮演的角色，而不是由客觀環境決定的其他角色。
跟隨者（follower）。再次強調，這不是乙個新概念，但是理解跟隨者的關鍵是跟隨者從領導者那裡接收日誌並複製它們，確保日誌保持一致。我們將在關於領導者選舉的部分中看到，跟隨者也會收到來自領導者的「心跳」訊息。如果領導者在一段可配置的時間內停止傳送這些訊息，跟隨者將發起一次領導者選舉，它們中的乙個將當選為新的領導者。
儘管選舉領導者的過程發生在排序節點的內部過程中，但是值得注意一下這個過程是如何工作的。
節點總是處於以下三種狀態之一：跟隨者、候選人或領導者。所有節點最初都是作為跟隨者開始的。在這種狀態下，他們可以接受來自領導者的日誌條目（如果其中乙個已經當選），或者為領導者投票。如果在一段時間內沒有接收到日誌條目或心跳（例如，5秒），節點將自己提公升到候選狀態。在候選狀態中，節點從其他節點請求選票。如果候選人獲得法定人數的選票，那麼他就被提公升為領導者。領導者必須接受新的日誌條目並將其複製到跟隨者。
往期精彩回顧:
區塊鏈知識系列
密碼學系列
零知識證明系列
共識系列
公鏈調研系列
位元幣系列
以太坊系列
eos系列
filecoin系列
聯盟鏈系列
fabric系列
智慧型合約系列
token系列
RAFT 區塊鏈中分布式共識協議
即便如此paxos演算法還是沒有得到重視，2001年lamport 覺得同行無法接受他的幽默感，於是用容易接受的方法重新表述了一遍 paxos made 可見lamport對paxos演算法情有獨鍾。近幾年paxos演算法的普遍使用也證明它在分布式一致性演算法中的重要地位。2006年google的三...
區塊鏈共識演算法 RAFT和PBFT的區別
這裡有個很形象的比喻 乙個團隊一定會有乙個老大和普通成員。對於 raft 演算法，共識過程就是 只要老大還沒掛，老大說什麼，我們 團隊普通成員 就做什麼，堅決執行。那什麼時候重新老大呢？只有當老大掛了才重選老大，不然生是老大的人，死是老大的鬼。對於 pbft 演算法，共識過程就是 老大向我傳送命令時...
區塊鏈共識機制
1 工作量證明共識機制pow proof of work 工作量證明是指使用者使用計算機算力耗電的成本，人稱挖礦，率先算出區塊唯一雜湊的礦工會得到這個區塊的獎勵，然後礦工們爭著計算出區塊的雜湊特定唯一值 這一數學問題答案 代表 位元幣 2 權益證明共識機制pos proof of stake 權益證...