Raft是一個一致性算法，旨在易於理解。它提供了Paxos的容錯和性能。不同之處在於它被分解為相對獨立的子問題，它清楚地解決了實際系統所需的所有主要部分。我們希望Raft能夠為更廣泛的受眾提供共識，並且這個更廣泛的受眾將能夠開發出比現在更多的高質量共識系統。
Raft是一個通過管理一個副本日志的一致性算法。它提供了跟(multi-)Paxos一樣有效的功能，但是它的架構和Paxos不一樣；它比Paxos更加容易理解，並且能用於生產環境中。為了加強理解，raft把一致性的問題分成了三個子問題，例如leader election, log replication, and safety,
Role
Leader，Follower，candidate
在Raft集群中，有且僅有一個Leader，在Leader運行正常的情況下，一個節點服務器要么就是Leader，要么就是Follower。Follower直到Leader故障了，才有可能變成candidate。
Leader負責把client的寫請求log復制到follower。它會和follower保持心跳。每個follower都有一個timeout時間（一般為150ms~300ms），在接受到心跳的時候，這個timeout時間會被重置。如果follower沒有接收到心跳，這些follower會把他們的狀態變為candidate，並且開啟新的一輪leader election。
term邏輯時鍾
Term相當於paxos中的proposerID，相當於一個國家的朝代。term是一段任意的時間序號。每一任Leader都有一個與之前不同的term。
當Leader選舉成功之后，一個節點成為了Leader，就會產生一個新的term，並且直到Leader故障，整個集群都會一直在這個term下執行操作。
如果leader選舉失敗了，則會再生成出一個term，再開啟一輪leader選舉。
Quorums：
多數派，意思是超過一半的機器存活，則這個機器可用，這個Quorums指的就是集群可用的指標。例如：集群中的節點數為2N，如果有N+1的機器存活，則代表集群可用，可接受請求，寫入log，應用到state machine中去，執行操作。如果少於N+1個機器存活，則代表集群可用，可接受請求，可寫入log，但不應用到state machine中去，不執行操作。
Leader Election
只有在下列兩種情況下才會進行leader election：
在第一次啟動raft集群的時候
在一個已存在的Leader故障的時候
選舉流程：
如果以上兩種任何一種發生了，所有的Follower無法再和Leader保持心跳，則它們都會等待一個（選舉）timeout，如果其中一個Follower的timeout最先到時，則這個Follower變成candidate開始選舉，
第一，增加term計數器，
第二，給自己投票並向所有其他的節點服務器請求投自己一票。
如果一個Follower在接受到投票請求時，接受到兩個term相同的投票請求時（也就是說，產生了兩個candidate），則在多個相同term的投票請求中，這個Follower只能給投給其中一個請求，只能投一票，並且按照先來先服務的原則投票。
如果這個candidate收到另外一個節點服務器的消息，並且這個節點服務器的term序號和當前的term序號一樣大，甚至更大的話，則這個candidate選舉失敗，從而它的狀態變成Follower，並且接受新的Leader。
如果一個candidate獲得了Quorums選票N+1(2N為集群中節點的數目)，則它變成新的leader。
如果多個candidate和多個Follower投完票之后，有多個candidate獲得了相同的票數，則會產生split vote，則新的term產生，重新選舉。Raft用隨機選舉timeout迅速地解決split vote問題，這個方法就是對於產生spit vote的candidates各自隨機生成一個選舉timeout，誰先到時，誰當leader，其他candidate都變為Follower。
當一個leader被選舉出來之后，就在Follower timeout到時變為candidate之前，發心跳信息給所有Followers。
Log Replication（Raft協議具體過程）
Leader負責把client的請求日志復制給其他Followers。
Raft協議具體過程就是通過復制狀態機的架構實現的，如下：
步驟：
Client發送請求給Leader，其中每個請求都是一條操作指令。
Leader接受到client請求之后，把操作指令(Entry)追加到Leader的操作日志中。緊接着對Follower發起AppendEntries請求、嘗試讓操作指令(Entry)追加到Followers的操作日志中，即落地。如果有Follower不可用，則一直嘗試。
一旦Leader接受到多數（Quorums）Follower的回應，Leader就會進行commit操作，每一台節點服務器會把操作指令交給狀態機處理。這樣就保證了各節點的狀態的一致性。
各服務器狀態機處理完成之后，Leader將結果返回給Client。
Saftety
Raft的安全性，體現在如下幾個方面：
Election safety:在一個term下，最多只有一個Leader。
Leader Append-Only:一個Leader只能追加新的entries，不能重寫和刪除entries
Log Matching:集群中各個節點的log都是相同一致的
Leader Completeness:如果一個log entry被committed了，則這個entry一定會出現在Leader的log里。
State Machine Safety:如果一個節點服務器的state machine執行了一個某個log entry命令，則其他節點服務器，也會執行這個log entry命令，不會再執行其他命令
之前四條，在前面都有所提及，而State Machine Safety是在Leader election過程中用到過。
State Machine Safety
一個candidate在選舉的時候，它會向其他節點服務器發送包含他的log的消息，獲取票數，如果它的log是最新的，則會獲取選票，如果它的log不是最新的，其他節點服務器還有更加新的log，則會拒絕給這個candidate投票。這就保證了State Machine Safety。
所以State Machine Safety保證的就是一個candidate必須擁有最新的log，才能獲取票數，才有機會贏得Leader選舉，才有機會成為Leader。
Follower crashes
如果一個follower故障了，則不會再接受AppendEntriesandvoterequests，並且Leader會不斷嘗試與這個節點保持心跳。
如果這個節點恢復了，則會接受Leader的最新的log，並且將log應用到state machine中去，執行log中的操作
方格指的是client發出的一條請求。
方格虛線，說明一條log entry寫入了log。
方格實線，說明一條log entry應用到state machine中
Leader crashes
則會進行Leader election。
如果碰到Leader故障的情況，集群中所有節點的日志可能不一致。
old leader的一些操作日志沒有通過集群完全復制。new leader將通過強制Followers復制自己的log來處理不一致的情況，步驟如下：
對於每個Follower，new leader將其日志與Followers的日志進行比較，找到他們的達成一致的最后一個log entry。
然后刪除掉Followers中這個關鍵entry后面的所有entry，並將其替換為自己的log entry。該機制將恢復日志的一致性。
下面這種情況集群中所有節點的日志可能不一致：
總結
Raft要求具備唯一Leader，並把一致性問題具體化為保持日志副本的一致性，以此實現相較Paxos而言更容易理解、更容易實現的目標。Raft是state machine system，Zab是primary-backup system。
引用
https://en.wikipedia.org/wiki/Raft_(computer_science)
https://raft.github.io/
http://thesecretlivesofdata.com/raft/
https://raft.github.io/raft.pdf
https://www.cnblogs.com/bangerlee/p/5991417.html
https://www.bilibili.com/video/av21667358/
https://en.wikipedia.org/wiki/State_machine_replication
https://github.com/CNiceToUpp/notes/blob/master/paxos%2Craft%2Czab/paper/In%20Search%20of%20an%20Understandable%20Consensus%20Algorithm.pdf
- 發表於: 2018-07-03
- 原文鏈接：https://kuaibao.qq.com/s/20180703G0J0GE00?refer=cp_1026