分散式一致性協議Raft全面詳解(建議收藏)

來源：mikechen的網際網路架構

談到分散式架構就不得不談到相關的分散式一致性協議，比如：Pasox、Raft等分散式一致性協議，本篇就來談談目前主流的Raft協議

Raft協議簡介

Raft是分散式的一致性協議，其相對Pasox更加簡單，都是為了實現 一致性 產生的，解決分散式系統的資料一致性和高可用。

Raft協議將一致性協議的核心內容分拆成為幾個關鍵階段：包括：領導選舉（leader selection）、日誌複製（log replication）等以簡化流程，提高協議的可理解性。

所以搞懂Raft協議重點就是要理解Raft協議角色，以及領導選舉、日誌複製這3大核心點，下面我分別詳解@mikechen

 

Raft協議角色

在Raft演算法中一個叢集裡面的所有節點有以下三種狀態：

Raft協議的每個副本都會處於三種狀態之一：Leader、Follower、Candidate。

1.跟隨者(follower)

類似選民，完全被動的角色，這樣的伺服器等待被通知投票。

2.候選者(candidate)

候選者就是在選舉過程中提名自己的實體，一旦選舉成功，則成為領導者。

3.領導者(leader)

領導者的作用：處理客戶端互動，日誌複製等動作，Raft 要求系統在任何一個時刻最多隻有一個 Leader，正常工作期間只有 Leader 和 Follower。

Raft 協議角色狀態轉換，如下圖所示：

 

領導leader選舉

Raft透過心跳機制來觸發leader選舉，當一個伺服器啟動時，預設位於followers狀態，並且一直持續知道它一直接受到leader的RPC請求。

leader會週期性傳送心跳給所有的followers，如果follower一段時間內沒有接受到心跳，那麼就認為當前沒有leader應該開始leader selection。

一個最小的 Raft叢集需要三個參與者，這樣才可能投出多數票，如下圖所示：

初始狀態下 ABC三個節點開始選舉Leader，Leader選舉過程中有三種可能的情形發生。

第一種：A節點要投自己一票，並把提議拉票請求發給B和C，如下圖所示：

B和C接受了A的提議，也投票給A，最終A成為Leader。

 

第二種：A節點投了自己一票，B節點也投了自己一票，C節點支援A節點的提議，如下圖所示：

第二種少數服從多數，最終A成為Leader。

 

第三種：A節點、B節點、C節點都各自投了自己一票，如下圖所示：

這樣就沒有節點獲得多數票，第三種情況本輪投票無效，出現了平票（Split Votes），因為沒有任何一方獲得多數票，所以要發起新的一輪投票。

Raft協議為了不讓選舉機制反覆出現平票，定義了一個隨機超時機制（randomized election timeouts），一旦發生平票，平票的節點會各自再來一次隨機timeout倒數，然後重新拉票，先發起拉票的節點就可以優先獲得了多數節點的投票。

 

日誌複製

在 Raft 演算法中需要實現分散式一致性的資料被稱作日誌， Raft 演算法中的資料提交記錄，會按照時間順序進行追加，Raft 也是嚴格按照時間順序並已一定的格式寫入日誌檔案中。

下面這張圖就描述了Raft叢集中日誌的組成結構：

每一個小方框就是entry，每個日誌項包含一條命令、任期資訊、日誌項在日誌中的位置資訊(索引值 LogIndex)。

1. 指令：由客戶端請求傳送的執行指令，有點繞口，我覺得理解成客戶端需要儲存的日誌資料即可。

2. 索引值：日誌項在日誌中的位置，需要注意索引值是一個連續並且單調遞增的整數。

3. 任期編號：建立這條日誌項的領導者的任期編號。

Raft 的日誌複製過程，大致如下圖所示：

1.領導者接收到客戶端發來的請求，建立一個新的日誌項，並將其追加到本地日誌中；

2.接著領導者透過追加條目 RPC 請求，將新的日誌項複製到跟隨者的本地日誌中；

3.當領導者收到大多數跟隨者的成功響應之後，則將這條日誌項應用到狀態機中，可以理解成該條日誌寫成功了；

4.最後領導者返回日誌寫成功的訊息響應客戶端。