raft的prevote實現機制
在basic raft演算法中，當乙個follower與其他節點網路隔離，如下圖所示：
follower_2在electiontimeout沒收到心跳之後,會發起選舉，並轉為candidate。每次發起選舉時，會把term加一。由於網路隔離，它既不會被選成leader，也不會收到leader的訊息，而是會一直不斷地發起選舉。term會不斷增大。
一段時間之後，這個節點的term會非常大。在網路恢復之後，這個節點會把它的term傳播到集群的其他節點，導致其他節點更新自己的term，變為follower。然後觸發重新選主，但這個舊的follower_2節點由於其日誌不是最新，並不會成為leader。整個集群被這個網路隔離過的舊節點擾亂，顯然需要避免的。
raft作者博士**《consensus: bridging theory and practice》的第9.6節 "preventing disruptions when a server rejoins the cluster"提到了prevote演算法的大概實現思路。
在prevote演算法中，candidate首先要確認自己能贏得集群中大多數節點的投票，這樣才會把自己的term增加，然後發起真正的投票。其他投票節點同意發起選舉的條件是（同時滿足下面兩個條件）：
沒有收到有效領導的心跳，至少有一次選舉超時。 candidate的日誌足夠新（term更大，或者term相同raft index更大）。
prevote演算法解決了網路分割槽節點在重新加入時，會中斷集群的問題。在prevote演算法中，網路分割槽節點由於無法獲得大部分節點的許可，因此無法增加其term。然後當它重新加入集群時，它仍然無法遞增其term，因為其他伺服器將一直收到來自leader節點的定期心跳資訊。一旦該伺服器從領導者接收到心跳，它將返回到follower狀態，term和leader一致。
prevote是乙個典型的2pc協議，第一階段先徵求其他節點是否同意選舉，如果同意選舉則發起真正的選舉操作，否則降為follower角色。這樣就避免了網路分割槽節點重新加入集群，觸發不必要的選舉操作。
Raft唯讀操作實現要點
leader直連 follower 客戶端可以鏈結任意節點，客戶端的指令會被follower 到leader來執行。唯讀操作也必須經過majority確認 唯讀操作一般只需要讀取當前節點的狀態機就可以了。但是存在網路分割槽的情況會導致當前的節點資料嚴重落伍。被分割槽隔離開來的leader和follo...
raft原理的動畫演示
過去,paxos一直是分布式協議的標準，但是paxos難於理解，更難以實現，google的分布式鎖系統chubby作為paxos實現曾經遭遇到很多坑。來自stanford的新的分布式協議研究稱為raft，它是乙個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。在了解raft之前，我們先了解...
raft演算法的核心思想
raft演算法跟paxos，zab zookeeper atomic broadcast 演算法類似，設計乙個一致性演算法，在乙個分布式系統中實現乙個分布式的 高可用的 一致性的儲存系統。raft的特點是設計簡單，易於程式設計師的理解和實現，並不是那麼抽象。raft演算法的核心思想和關鍵技術點 保證...