文章目錄
-
- 1、什麼是Raft
- 2、Raft相關概念
- 3、原了解析
-
- 3.1、日志複制
- 3.2、Leader選舉
- 3.3、Leader節點當機
- 3.4、多個Candidate競争選舉
- 3.5、網絡分區處理
- 4、總結
- 5、參考
1、什麼是Raft
Paxos 是論證了一緻性協定的可行性，但是論證的過程據說晦澀難懂，缺少必要的實作細節，而且
工程實作難度比較高, 廣為人知實作隻有 zk 的實作 zab 協定。
Paxos協定的出現為分布式強一緻性提供了很好的理論基礎，但是Paxos協定了解起來較為困難，
實作比較複雜。
然後斯坦福大學RamCloud項目中提出了易實作，易了解的分布式一緻性複制協定 Raft。Java，
C++，Go 等都有其對應的實作之後出現的Raft相對要簡潔很多。引入主節點，通過競選确定主節點。節
點類型：Follower、Candidate 和 Leader。
- Leader 會周期性的發送心跳包給 Follower。每個 Follower 都設定了一個随機的競選逾時時間（我想稱它為“靜默時間”），一般為 150ms~300ms；
- 如果在這個時間内沒有收到 Leader 的心跳包，就會變成 Candidate（靜默期已到，哥們我要出山了），進入競選階段；
- 通過競選階段的投票多的人成為Leader（當老大了）。
2、Raft相關概念
節點狀态：
- Leader（主節點）：接受 Client 更新請求，寫入本地後，然後同步到其他副本中。
-
Follower（從節點）：從 Leader 中接受更新請求，然後寫入本地日志檔案。對用戶端提供讀
請求。
-
Candidate（候選節點）：如果 Follower 在一段時間内未收到 leader 心跳。則判斷 leader
可能故障，發起選主提議。節點狀态從 Follower 變為 Candidate 狀态，直到選主結束。
Election Timeout：
選舉逾時時間（可以被重置）。是節點狀态從Follower變為Candidate的時間，是一個150ms～300ms的随機值。
Heartbeat Timeout：
心跳逾時時間。Leader節點會以固定的時間間隔定時給Follower節點發送心跳。
Election Term：
選舉輪次。初始值為0，當某個節點從Follower 變為 Candidate時該節點的Term會加1。Term值越大表示目前leader越新。
Request Vote：
請求投票，Candidate 在選舉過程中發起，收到多數派響應後，成為 Leader。
3、原了解析
Raft提供兩個核心過程：日志複制和Leader選舉。
3.1、日志複制
1、來自用戶端的修改都會被傳入 Leader。注意該修改還未被送出，隻是寫入日志中。
2、Leader 會把修改複制到所有 Follower。
3、Leader 會等待大多數的 Follower 也進行了修改，然後才将修改送出。
4、此時 Leader 會通知的所有 Follower 讓它們也送出修改，此時所有節點的值達成一緻。
3.2、Leader選舉
1、初始階段，隻有 Follower，沒有 Leader。Follower A 優先等待一個随機的Election Timeout（競選逾時時間）之後，沒收到 Leader 發來的心跳包，是以進入競選階段。
2、A 發送投票請求給其它所有節點。
3、其它節點如果在目前Term沒有投過票則會對請求進行回複，如果超過一半的節點回複了，那麼該 Candidate 就會變成 Leader。
4、之後 Leader 會根據Heartbeat Timeout周期性地發送心跳包給 Follower，Follower 接收到心跳包，會重置Election Timeout。
3.3、Leader節點當機
當之前選舉的Leader A當機，節點B和節點C在選舉逾時時間内沒有收到Leader的心跳續約包，其中節點B優先結束選舉逾時時間即變為Candidate。
後續的流程和之前一樣，隻不過當機的節點A不會做出任何響應。
3.4、多個Candidate競争選舉
1、如果有多個 Follower 成為 Candidate，并且所獲得票數相同，那麼就需要重新開始投票。
2、當重新開始投票時，由于每個節點設定的随機競選逾時時間不同，是以下一次再次出現多個Candidate 并獲得同樣票數的機率很低。
3.5、網絡分區處理
1、當出現網絡分區後，如果某個分區沒有Leader則會進行Leader選舉。
2、當網絡分區恢複後，多個分區裡面的Leader取Term最大的一個作為分區恢複以後整個叢集的Leader，然後向其他節點同步自己的資料。
4、總結
Raft是在Paxos協定基礎上的一個便于了解，便于實作的分布式一緻性協定。也經常被用在分布式系統和軟體當中，其中就包括了大名鼎鼎的Redis，兩者都是保證了CAP理論中的“AP”。
通過了解也發現Raft的Leader選舉和日志複制過程巧妙又有趣，對于入門分布式，以及了解分布式系統面臨的問題有很大的幫助。
5、參考
Raft動畫示範：http://thesecretlivesofdata.com/raft/#home。