我們先來看乙個例子：
我們有乙個單節點node，這個節點可以是資料庫，也可以是一台伺服器，當client向node傳送data時，x節點收到data，記錄下來
由此可見對於單個節點，一致性是很容易實現的。
然而對於多個節點，我們如何來實現一致性，這就是分布式一致性的問題。
raft就是乙個實現分布式一致性的協議
下面讓我們來看看它是如何工作的？
每乙個節點有三種state
（1） follower state
（2） leader state
（3） candidate state
所有的節點都是從follower state開始的，如果乙個follower狀態的節點沒有被某個leader所控制，它就有可能成為候選者。而當乙個節點成為候選者時，它就會向其他節點收集選票，而其他節點在收到候選者發出的訊號後，就會把選票發給候選者。如果某個候選者獲取了大多數選票，則會成為領導者。這個過程就是領導者選舉。
整個選舉過程是有乙個時間限制的，如下圖：
splite vote是因為如果同時有兩個候選人向大家邀票，這時通過類似加時賽來解決，兩個候選者在一段timeout比如300ms互相不服氣的等待以後，因為雙方得到的票數是一樣的，一半對一半，那麼在300ms以後，再由這兩個候選者發出邀票，這時同時的概率大大降低，那麼首先發出邀票的的候選者得到了大多數同意，成為領導者leader，而另外乙個候選者後來發出邀票時，那些follower選民已經投票給第乙個候選者，不能再投票給它，它就成為落選者了，最後這個落選者也成為普通follower一員了。
選出領導者後，對於這些節點組成的乙個系統中的所有變化都會經過這個領導者，由它掌管全域性。
領導者收到client發來的訊息後，會把每一次的請求操作記錄在日誌上，在這條日誌記錄沒被提交之前，其他節點的值不會有任何改變。
領導者先把日誌條目set 5 拷貝到跟隨者節點中，當大多數的跟隨者節點已經把日誌記錄追加到本節點的日誌時，領導者就開始執行該條日誌，即把5寫入改節點。然後在下乙個heartbeat中，領導者就會通知followers，該日誌條目已經提交，follows也會寫入5。這時整個集群保持了資料的一致性。這個過程叫做日誌複製。
對於每個新的日誌記錄，重複上述過程。
如果在這一過程中，發生了網路分割槽或者網路通訊故障，使得leader不能訪問大多數follwers了，那麼leader只能正常更新它能訪問的那些follower伺服器，而大多數的伺服器follower因為沒有了leader，他們重新選舉乙個候選者作為leader，然後這個leader作為代表於外界打交道，如果外界要求其新增新的日誌，這個新的leader就按上述步驟通知大多數followers，如果這時網路故障修復了，那麼原先的leader就變成follower，在失聯階段這個老leader的任何更新都不能算commit，都回滾，接受新的leader的新的更新。
分布式系統一致性演算法Raft
raft 演算法也是一種少數服從多數的演算法，在任何時候乙個伺服器可以扮演以下角色之一 leader 負責 client 互動 和 log 複製，同一時刻系統中最多存在乙個 follower 被動響應請求 rpc，從不主動發起請求 rpc candidate 由follower 向leader轉換的...
分布式系統的Raft演算法 一致性演算法
原文出處 過去,paxos一直是分布式協議的標準，但是paxos難於理解，更難以實現，google的分布式鎖系統chubby作為paxos實現曾經遭遇到很多坑。來自stanford的新的分布式協議研究稱為raft，它是乙個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。在了解raft之前，...
共識演算法（三） Raft（分布式一致性演算法）
raft替代了paxos 太複雜 並提供了一種在計算系統集群中分布狀態機的通用方法，確保集群中的每個節點都同意一系列相同的狀態轉換，也就是說，它在提供的計算機集群分布狀態機時，有個別或者多個狀態機down掉了，從而使其狀態不統一並影響了consensus一致性，繼而影響了整個系統的執行，而raft演...