Paxos自1990年提出以後，相當長時間內幾乎已成爲分佈式一致性算法的代名詞。但因其難以理解和實現，目前知名實現僅有Chubby、Zookeeper、libpaxos幾種，其中Zookeeper使用的ZAB對Paxos做了大量改進。爲此，2013年斯坦福的Diego Ongaro、John Ousterhout，提出了新的更易理解和實現的一致性算法，即Raft。
Raft和Paxos均只要保證n/2+1節點正常，即可服務。相比Paxos，其優勢即爲易於理解和實現。Raf將算法分解爲：選擇領導者、日誌複製、安全性等幾個子問題。它的流程即爲：開始時在集羣中選舉出Leader負責日誌複製的管理，Leader接收來自客戶端的事務請求（日誌），並將它們複製給集羣中的其他節點，然後通知集羣中的其他節點提交日誌，Leader負責保證其他節點與它的日誌同步。當Leader宕機時，集羣其他節點重新發起選舉，選出的新的Leader。
角色
Raft涉及三種角色：
Leader：即領導者，負責處理來自客戶端的請求，管理日誌複製、以及與Follower保持心跳以維持其領導者地位。
Follower：即追隨者，負責響應來自Leader的日誌複製請求，響應來自Candidate的選舉請求。初始時所有節點均爲Follower。
Candidate：即候選者，負責發起選舉投票，Raft啓動後或Leader宕機後，一個節點從Follower轉爲Candidate，併發起選舉，選舉成功後，由Candidate轉爲Leader。
如下爲Raft角色狀態轉換圖：
Term（任期）
在Raft中使用了Term（任期）的概念，一輪選舉即爲一個Term（任期），一個Term中僅能產生一個Leader。Term使用連續遞增的編號表示，初始時所有Follower的Term均爲1。其中某個Follower定時器到期觸發選舉，其狀態轉換爲Candidate，此時Term加1變爲2，然後開始選舉，有如下幾種可能：
1、如果當前Term爲2的任期內沒有選舉出Leader或出現異常，Term遞增爲3，並開始新一輪選舉。
2、此輪Term爲2的任期內選舉出Leader後，如果Leader宕機，此時其他Follower轉爲Candidate，Term遞增，併發起新的選舉。
3、如果Leader或Candidate發現自己的Term比其他Follower小時，Leader或Candidate轉爲Follower，Term遞增。
4、如果Follower發現自己的Term比其他Follower小時，更新Term與其他Follower保持一致。
每次Term遞增都將發生新一輪選舉，在Raft正常運行過程中，所有節點Term均一致。如果節點不發生故障，一個Term（任期）會一直保持下去，當某節點收到的請求中Term比當前Term小時拒絕請求。
選舉
初始時所有節點均爲Follower，且定時器時間不同。某個節點定時器觸發選舉後，Term遞增，該節點由Follower轉換爲Candidate，向其他節點發起投票請求（RequestVote RPC）。有如下幾種可能：
1、收到過半數節點（n/2+1）投票，由Candidate轉換爲Leader，向其他節點發送心跳以維持領導者地位。
2、如果收到其他節點發送的AppendEntries RPC請求，且該節點Term大於當前節點Term，即發現了新的有效領導者，轉換爲Follower，否則保持Candidate拒絕該請求。
3、選舉超時，Term遞增，重新發起選舉。
每輪Term期間，每個節點均只能投票1次，如果多個Candidate均沒有接收到過半數投票，則每個Candidate Term遞增，重啓定時器並重新發起選舉。因定時器時間隨機，因此不會多次出現多個Candidate同時發起投票的問題。
日誌複製
保證節點的一致性，就要保證所有節點都按順序執行相同的操作序列，日誌複製目的即爲此。
1、Leader接收到客戶端事務請求（即日誌），先將日誌追加到本地Log中，並通過AppendEntries RPC複製給其他Follower。
2、Follower接收到日誌後，追加到本地Log中，並向Leader發送ACK消息。
3、Leader收到過半數Follower的ACK消息後，將日誌置爲已提交併正式提交日誌，通知客戶端，併發送AppendEntries RPC請求通知Follower提交日誌。
安全性
1、每個Term期間只能選舉一個Leader。
2、Leader不會刪除或覆蓋已有日誌條目，只會追加。
3、如果相同索引位置的日誌條目Term任期號相同，那麼認爲從頭到這個索引位置均相同。
4、如果某個日誌條目在某任期內提交，那麼這個日誌條目必然出現在更大的Term任期號的所有領導中。
5、如果Leader在某索引位置的日誌條目已提交，那麼其他節點相同索引位置不會提交不同的日誌條目。
RequestVote RPC和AppendEntries RPC
Raft中節點通信使用兩種RPC，即RequestVote RPC和AppendEntries RPC：
RequestVote RPC：即請求投票，由Candidate在選舉期間發起。
AppendEntries RPC：即附加條目RPC，由Leader發起，用於日誌複製和心跳機制。
參考文檔
尋找一種易於理解的一致性算法（擴展版）
一致性算法Raft詳解
Raft 爲什麼是更易理解的分佈式一致性算法
後記
本文總結的Raft，及之前文章中的Paxos、2PC、3PC均爲基於非拜占庭容錯的分佈式一致性算法，即除考慮消息的丟失、超時、亂序，但不考慮消息被篡改。從下個文章起，將總結基於拜占庭容錯的分佈式一致性算法，該算法在比特幣、以太坊、及其他區塊鏈產品中廣泛使用。