paxos演算法是最早的強一致性演算法，2023年被leslie lamport提出，但是由於其難以理解和實現，導致沒有被廣泛使用。因此，2023年raft演算法被提出，功能與paxos演算法相同，更易於理解，實現簡單，因此迅速被廣泛推廣使用，已經成為當前主流的強一致性演算法。（從cap角度，raft演算法選擇了cp，捨棄了a，選主期間會出現短暫的不可用）
term
term為邏輯時鐘，用來比較資料的新舊、leader的新老、請求是否過時等，每次選舉產生新的term，如下圖所示：
角色/狀態raft演算法可以分為leader election選主和log replication日誌複製兩部分。演算法的整體流程是：首先，集群中的節點擊舉出乙個主節點；然後，由主節點處理客戶端的所有請求，並負責將請求複製到所有的從節點，保證節點間的資料一致性。
leader election
raft演算法通過心跳機制來進行選主，具體過程如下：
節點啟動時，初始狀態為follower，並開始倒計時。如果election timeout時間內，收到leader的心跳，則重新開始計時；如果超時，則發起選主；
開始選主後，節點的狀態從follower轉變為candidate，當前任期加1，向集群所有節點傳送投票請求（包括節點本身）；
# 投票資訊
term：候選節點的所在的任期；
candidateid：候選節點id；
lastlogindex：候選節點最後一條日誌的索引；
lastlogterm：候選節點最後一條日誌的任期；
leader節點擊出之後，會負責client所有請求以及節點間的資料同步，具體過程如下：
client傳送請求到leader節點，如果其它節點接收到會**到leader節點；
leader節點接收到請求後，首先將請求命令寫入本地日誌（未提交狀態），然後發日誌複製命令送至集群其它節點；
其它節點接收到日誌複製命令後，會根據命令資訊進行判斷：如果根據index和term能找到本地記錄則寫入，否則拒絕；
如果leader節點接收到大部分節點的ack，則認為日誌複製成功，本地資料狀態變為commited，給客戶端返回ack，並傳送commit請求到集群其它節點；如果leader節點接收到拒絕請求，會減小index，繼續重試直到找到匹配的記錄，然後開始複製；
不一致處理規則：raft演算法中，leader節點日誌只會追加，沒有修改和刪除，並且資料流向永遠都是從leader到其它節點（單向的），如果發現不一致，處理規則就是強制其它節點複製leader資料，覆蓋不一致資料。
參考github位址
raft為什麼是更易理解的分布式一致性演算法
分布式一致性演算法Raft
我們先來看乙個例子 我們有乙個單節點node，這個節點可以是資料庫，也可以是一台伺服器，當client向node傳送data時，x節點收到data，記錄下來 由此可見對於單個節點，一致性是很容易實現的。然而對於多個節點，我們如何來實現一致性，這就是分布式一致性的問題。raft就是乙個實現分布式一致性...
分布式系統的Raft演算法 一致性演算法
原文出處 過去,paxos一直是分布式協議的標準，但是paxos難於理解，更難以實現，google的分布式鎖系統chubby作為paxos實現曾經遭遇到很多坑。來自stanford的新的分布式協議研究稱為raft，它是乙個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。在了解raft之前，...
共識演算法（三） Raft（分布式一致性演算法）
raft替代了paxos 太複雜 並提供了一種在計算系統集群中分布狀態機的通用方法，確保集群中的每個節點都同意一系列相同的狀態轉換，也就是說，它在提供的計算機集群分布狀態機時，有個別或者多個狀態機down掉了，從而使其狀態不統一並影響了consensus一致性，繼而影響了整個系統的執行，而raft演...