raft替代了paxos（太複雜），並提供了一種在計算系統集群中分布狀態機的通用方法，確保集群中的每個節點都同意一系列相同的狀態轉換，也就是說，它在提供的計算機集群分布狀態機時，有個別或者多個狀態機down掉了，從而使其狀態不統一並影響了consensus一致性，繼而影響了整個系統的執行，而raft演算法就可以解決這個問題，它允許有down機，從而可以避免影響整個系統的執行。乙個raft集群包含若干個伺服器節點，通常是5個，這允許整個系統容忍2個節點的失效，每個節點處於一下三種狀態之一：
follower（跟隨者） ：所有節點都以 follower 的狀態開始。如果沒收到 leader 訊息則會變成 candidate 狀態。
candidate（候選人）：會向其他節點「拉選票」，如果得到大部分的票則成為 leader，這個過程就叫做 leader 選舉(leader election)。
leader（領導者）：所有對系統的修改都會先經過 leader 。
raft分為兩個階段
第乙個階段：選舉：從集群中選出乙個合適的節點作為leader。即計算機集群開始執行時，每個節點都是follower狀態，當term週期過後，就會有folloer節點成為conmidited節點，並給自己投一票，然後將自己通過rpc廣播出去，讓其他的節點投票給自己，其他節點收到它的廣播後，首先會檢查自己的票是否已經投出，如果沒有投出或者votefor為null，則就會檢查競選節點的日誌資訊是否比當前節點更全，如果不全，則拒絕投票，反之則投給它，當自己的票屬於一大半時，則競選通過，轉為leader，然後再將自己的資訊同步給其他節點。
日誌同步：1.選舉出的leader接收客戶端請求，將其轉為raft日誌。2.leader將日誌同步到其他節點，當大多數節點已經同步完畢日誌後，日誌的狀態就會變為conmmited，從而這些日誌將不會被篡改。3.當leader節點down掉後，會重新執行第一階段。
raft日誌衝突：
如果follower節點的資料與leader節點資料發生衝突，則同步leader節點的資料，刪除自己本身的髒資料。
分布式一致性演算法Raft
我們先來看乙個例子 我們有乙個單節點node，這個節點可以是資料庫，也可以是一台伺服器，當client向node傳送data時，x節點收到data，記錄下來 由此可見對於單個節點，一致性是很容易實現的。然而對於多個節點，我們如何來實現一致性，這就是分布式一致性的問題。raft就是乙個實現分布式一致性...
分布式系統一致性演算法Raft
raft 演算法也是一種少數服從多數的演算法，在任何時候乙個伺服器可以扮演以下角色之一 leader 負責 client 互動 和 log 複製，同一時刻系統中最多存在乙個 follower 被動響應請求 rpc，從不主動發起請求 rpc candidate 由follower 向leader轉換的...
分布式系統的Raft演算法 一致性演算法
原文出處 過去,paxos一直是分布式協議的標準，但是paxos難於理解，更難以實現，google的分布式鎖系統chubby作為paxos實現曾經遭遇到很多坑。來自stanford的新的分布式協議研究稱為raft，它是乙個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。在了解raft之前，...