原文出處：
過去, paxos一直是分布式協議的標準，但是paxos難於理解，更難以實現，google的分布式鎖系統chubby作為paxos實現曾經遭遇到很多坑。
來自stanford的新的分布式協議研究稱為raft，它是乙個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。
在了解raft之前，我們先了解consensus一致性這個概念，它是指多個伺服器在狀態達成一致，但是在乙個分布式系統中，因為各種意外可能，有的伺服器可能會崩潰或變得不可靠，它就不能和其他伺服器達成一致狀態。這樣就需要一種consensus協議，一致性協議是為了確保容錯性，也就是即使系統中有一兩個伺服器當機，也不會影響其處理過程。
為了以容錯方式達成一致，我們不可能要求所有伺服器100%都達成一致狀態，只要超過半數的大多數伺服器達成一致就可以了，假設有n臺伺服器，n/2 +1 就超過半數，代表大多數了。
paxos和raft都是為了實現consensus一致性這個目標，這個過程如同選舉一樣，參選者需要說服大多數選民(伺服器)投票給他，一旦選定後就跟隨其操作。paxos和raft的區別在於選舉的具體過程不同。
在raft中，任何時候乙個伺服器可以扮演下面角色之一：
leader: 處理所有客戶端互動，日誌複製等，一般一次只有乙個leader.
follower: 類似選民，完全被動
candidate候選人: 類似proposer律師，可以被選為乙個新的領導人。
raft階段分為兩個，首先是選舉過程，然後在選舉出來的領導人帶領進行正常操作，比如日誌複製等。下面用圖示展示這個過程：
1. 任何乙個伺服器都可以成為乙個候選者candidate，它向其他伺服器follower發出要求選舉自己的請求：
2. 其他伺服器同意了，發出ok。
注意如果在這個過程中，有乙個follower當機，沒有收到請求選舉的要求，因此候選者可以自己選自己，只要達到n/2 + 1 的大多數票，候選人還是可以成為leader的。
3. 這樣這個候選者就成為了leader領導人，它可以向選民也就是follower們發出指令，比如進行日誌複製。
4. 以後通過心跳進行日誌複製的通知
5. 如果一旦這個leader當機崩潰了，那麼follower中有乙個成為候選者，發出邀票選舉。
6. follower同意後，其成為leader，繼續承擔日誌複製等指導工作：
值得注意的是，整個選舉過程是有乙個時間限制的，如下圖：
splite vote是因為如果同時有兩個候選人向大家邀票，這時通過類似加時賽來解決，兩個候選者在一段timeout比如300ms互相不服氣的等待以後，因為雙方得到的票數是一樣的，一半對一半，那麼在300ms以後，再由這兩個候選者發出邀票，這時同時的概率大大降低，那麼首先發出邀票的的候選者得到了大多數同意，成為領導者leader，而另外乙個候選者後來發出邀票時，那些follower選民已經投票給第乙個候選者，不能再投票給它，它就成為落選者了，最後這個落選者也成為普通follower一員了。
下面以日誌複製為例子說明raft演算法，假設leader領導人已經選出，這時客戶端發出增加乙個日誌的要求，比如日誌是"sally"：
2. leader要求followe遵從他的指令，都將這個新的日誌內容追加到他們各自日誌中：
3.大多數follower伺服器將日誌寫入磁碟檔案後，確認追加成功，發出commited ok:
4. 在下乙個心跳heartbeat中，leader會通知所有follwer更新commited 專案。
對於每個新的日誌記錄，重複上述過程。
如果在這一過程中，發生了網路分割槽或者網路通訊故障，使得leader不能訪問大多數follwers了，那麼leader只能正常更新它能訪問的那些follower伺服器，而大多數的伺服器follower因為沒有了leader，他們重新選舉乙個候選者作為leader，然後這個leader作為代表於外界打交道，如果外界要求其新增新的日誌，這個新的leader就按上述步驟通知大多數followers，如果這時網路故障修復了，那麼原先的leader就變成follower，在失聯階段這個老leader的任何更新都不能算commit，都回滾，接受新的leader的新的更新。
總結：目前幾乎所有語言都已經有支援raft演算法的庫包，具體可參考：raftconsensus.github.io
分布式一致性演算法Raft
我們先來看乙個例子 我們有乙個單節點node，這個節點可以是資料庫，也可以是一台伺服器，當client向node傳送data時，x節點收到data，記錄下來 由此可見對於單個節點，一致性是很容易實現的。然而對於多個節點，我們如何來實現一致性，這就是分布式一致性的問題。raft就是乙個實現分布式一致性...
分布式系統一致性演算法Raft
raft 演算法也是一種少數服從多數的演算法，在任何時候乙個伺服器可以扮演以下角色之一 leader 負責 client 互動 和 log 複製，同一時刻系統中最多存在乙個 follower 被動響應請求 rpc，從不主動發起請求 rpc candidate 由follower 向leader轉換的...
共識演算法（三） Raft（分布式一致性演算法）
raft替代了paxos 太複雜 並提供了一種在計算系統集群中分布狀態機的通用方法，確保集群中的每個節點都同意一系列相同的狀態轉換，也就是說，它在提供的計算機集群分布狀態機時，有個別或者多個狀態機down掉了，從而使其狀態不統一並影響了consensus一致性，繼而影響了整個系統的執行，而raft演...