乙個 raft 集群包含若干個伺服器節點；通常是 5 個，這允許整個系統容忍 2 個節點的失效，每個節點處於以下三種狀態之一：
raft通過選出乙個leader來簡化日誌副本的管理，例如，日誌項(log entry)只允許從leader流向follower。
基於leader的方法，raft演算法可以分解成三個子問題：
leader election(領導選舉)：原來的leader掛掉後，必須選出乙個新的leader
log replication(日誌複製)：leader從客戶端接收日誌，並複製到整個集群中
safety(安全性)：如果有任意的server將日誌項回放到狀態機中了，那麼其他的server只會回放相同的日誌項
raft 使用一種心跳機制來觸發領導人選舉。當伺服器程式啟動時，他們都是follower(跟隨者) 身份。如果乙個跟隨者在一段時間裡沒有接收到任何訊息，也就是選舉超時，然後他就會認為系統中沒有可用的領導者然後開始進行選舉以選出新的領導者。要開始一次選舉過程，follower會給當前term加1並且轉換成candidate狀態。
然後他會並行的向集群中的其他伺服器節點傳送請求投票的 rpcs 來給自己投票。候選人的狀態維持直到發生以下任何乙個條件發生的時候，
其他的伺服器成為領導者
如果在等待選舉期間，candidate接收到其他server要成為leader的rpc，分兩種情況處理：
一段時間之後沒有任何乙個獲勝的人
raft的log replication保證以下性質(log matching property)：
其中特性一通過以下保證：
特性二通過以下保證：
如果follower沒有發現與它一樣的log entry，那麼它會拒絕接受新的log entry 這樣就能保證特性二得以滿足。
在一些一致性演算法中，即使一台server沒有包含所有之前已提交的log entry，也能被選為主，這些演算法需要把leader上缺失的日誌從其他的server拷貝到leader上，這種方法會導致額外的複雜度。相對而言，raft使用一種更簡單的方法，即它保證所有已提交的log entry都會在當前選舉的leader上，因此，在raft演算法中，日誌只會從leader流向follower。
為了實現上述目標，raft在選舉中會保證，乙個candidate只有得到大多數的server的選票之後，才能被選為主。得到大多數的選票表明，選舉它的server中至少有乙個server是擁有所有已經提交的log entry的，而leader的日誌至少和follower的一樣新，這樣就保證了leader肯定有所有已提交的log entry。
領導人知道一條當前任期內的日誌記錄是可以被提交的，只要它被儲存到了大多數的伺服器上。如果乙個領導人在提交日誌條目之前崩潰了，未來後續的領導人會繼續嘗試複製這條日誌記錄。然而，乙個領導人不能斷定乙個之前任期裡的日誌條目被儲存到大多數伺服器上的時候就一定已經提交了。下圖展示了一種情況，一條已經被儲存到大多數節點上的老日誌條目，也依然有可能會被未來的領導人覆蓋掉。
如上圖的例子，圖（c）就發生了乙個log entry雖然已經複製到大多數的伺服器，但是仍然有可能被覆蓋掉的可能，如圖（d），整個發生的時序如下：
為了上圖描述的情況，raft 永遠不會通過計算副本數目的方式去提交乙個之前任期內的日誌條目。只有領導人當前任期裡的日誌條目通過計算副本數目可以被提交；一旦當前任期的日誌條目以這種方式被提交，那麼由於日誌匹配特性，之前的日誌條目也都會被間接的提交。例如，圖e中，如果s1在掛掉前把log entry(4)複製到了大多數的server後，就能保證之前的log entry（2）被提交了，之後s5也就不可能被選為領導者了。
以反證法來證明，假設任期 t 的領導人（領導人 t）在任期內提交了一條日誌條目，但是這條日誌條目沒有被儲存到未來某個任期的領導人的日誌中。設大於 t 的最小任期 u 的領導人 u 沒有這條日誌條目。
如果 s1 （任期 t 的領導者）提交了一條新的日誌在它的任期裡，然後 s5 在之後的任期 u 裡被選舉為領導人，然後至少會有乙個機器，如 s3，既擁有來自 s1 的日誌，也給 s5 投票了。在領導人 u 選舉的時候一定沒有那條被提交的日誌條目（領導人從不會刪除或者覆蓋任何條目）。
領導人 t 複製這條日誌條目給集群中的大多數節點，同時，領導人u 從集群中的大多數節點贏得了選票。因此，至少有乙個節點（投票者、選民）同時接受了來自領導人t 的日誌條目，並且給領導人u 投票了，這個投票者是產生這個矛盾的關鍵。
這個投票者必須在給領導人 u 投票之前先接受了從領導人 t 發來的已經被提交的日誌條目；否則他就會拒絕來自領導人 t 的附加日誌請求（因為此時他的任期號會比 t 大）。
投票者在給領導人 u 投票時依然保有這條日誌條目，因為任何中間的領導人都包含該日誌條目（根據上述的假設），領導人從不會刪除條目，並且跟隨者只有和領導人衝突的時候才會刪除條目。
投票者把自己選票投給領導人 u 時，領導人 u 的日誌必須和投票者自己一樣新。這就導致了兩者矛盾之一。
因此，假設不成立，所有比 t 大的領導人一定包含了所有來自 t 的已經被提交的日誌。日誌匹配原則保證了未來的領導人也同時會包含被間接提交的條目
跟隨者或者候選人崩潰，會按如下處理：
領導人選舉是 raft 中對時間要求最為關鍵的方面。raft 可以選舉並維持乙個穩定的領導人,只要系統滿足下面的時間要求：
廣播時間（broadcasttime） << 選舉超時時間（electiontimeout） << 平均故障間隔時間（mtbf）選舉超時時間要小於mtbf的原因是，防止選舉時，能正常工作的server沒有達到大多數。
對於廣播時間，一般在[0.5ms,20ms]之間，而平均故障間隔時間一般非常大，至少是按照月為單位。因此，一般選舉超時時間一般選擇範圍為[10ms,500ms]。因此，當領導者掛掉後，能在較短時間內重新選主。
raft 一致性演算法
redis使用raft leader election進行master選舉。概念 乙個cluster中有多個node，最終狀態有乙個leader，多個follower。leader通過heartbeat週期性和follower通訊。node有三種狀態 leader，follower，candidat...
raft一致性演算法
過去,paxos一直是分布式協議的標準，但是paxos難於理解，更難以實現，google的分布式鎖系統chubby作為paxos實現曾經遭遇到很多坑。來自stanford的新的分布式協議研究稱為raft，它是乙個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。在了解raft之前，我們先了解...
Raft一致性協議
什麼是raft協議？我們應當知道，分布式儲存系統通常通過維護多個副本來進行容錯，提高系統的可用性。要實現此目標，就必須要解決分布式儲存系統的最核心問題 維護多個副本的一致性。raft協議就可以完成這個操作。為什麼用raft？除了raft，還有很多協議可以實現這個功能，比如說 兩階段提交協議，三階段提...