Raft協議是分布式領域解決一致性的又一著名協議，主要包含Leader選舉、日志復制兩個部分。

1、Leader選舉

1.1  單節點發起的投票

Raft協議中節點有3種狀態（角色）：

• Follower
  跟隨者。

• Candidate
  候選者。

• Leader
  領導者(Leader)，通常我們所說的的主節點。

首先3個節點初始狀態為 Follower，每個節點會有一個超時時間(計時器)，其時間設置為150ms~300ms之間的隨機值。當計時器到期后，節點狀態從 Follower 變成 Candidate，如下圖所示：

 

當節點狀態為 Candidate，將發起一輪投票，由于是第一輪投票，設置本輪投票輪次為1，并首先為自己投上一票，正如上圖所示的 NodeA 節點，Term 為1，Vote Count為1。

 

 

 

 

 

例如NodeA節點宕機，停止向它的從節點發送心跳，我們來看一下集群如何進行重新選主。

 

節點B，首先將投票輪次設置為2，然后首先為自己投上一篇，然后向其他節點發起投票請求。  
 

 

3個節點的選主就介紹到這里了，也許有網友會說，雖然各個節點的計時器是隨機的，但也有可能同一時間，或一個節點在未收到另一個節點發起的投票請求之前變成 Candidate，即在一輪投票過程中，有大于1個的節點狀態都是 Candidate，那該如何選主呢？

下面以4個節點的集群為例，來闡述上述這種情況情況下，如何進行選主。

1.2 多節點同時發起的投票

首先同時有兩個節點進入Candidate狀態，并開始新的一輪投票，當前投票編號為4，首先先為自己投上一票，然后向集群中的其他節點發起投票，如下圖所示：

 

 

 

 

 

1.3 思考如何實現Raft選主

1. 節點狀態
   需要引入3種節點狀態：Follower(跟隨者)、Candidate(候選者)，投票的觸發點，Leader(主節點)。

2. 進入投票狀態的計時器
   Follower、Candidate 兩個狀態時，需要維護一個計時器，每次定時時間從150ms-300ms之間進行隨機，即每個節點的每次的計時過期不一樣，Follower狀態時，計時器到點后，觸發一輪投票。節點在收到投票請求、Leader 的心跳請求并作出響應后需要重置定時器。

3. 投票輪次Team
   Candidate 狀態的節點，每發起一輪投票，Term 加一；Term的存儲。

4. 投票機制
   每一輪一個節點只能為一個節點投贊成票，例如節點A中維護的輪次為3，并且已經為節點B投了贊成票，如果收到其他節點，投票輪次為3，則會投反對票，如果收到輪次為4的節點，是又可以投贊成票的。

5. 成為Leader的條件
   必須得到集群中節點的大多數，即超過半數，例如如果集群中有3個節點，則必須得到兩票，如果其中一臺服務器宕機，剩下的兩個節點，還能進行選主嗎？答案是可以的，因為可以得到2票，超過初始集群中3的一半，所以通常集群中的機器各位盡量為奇數，因為4臺的可用性與3臺的一樣。

溫馨提示：上述結論只是我的一些思考，我們可以帶著上述思考，進入到Dleger的學習中，下一篇將從源碼分析的角度來學習大神是如何實現Raft協議的Leader選主的，讓我們一起期待吧。

2、日志復制

完成集群內的選主工作后，客戶端向主節點發送請求，由主節點負責數據的復制，使集群內的數據保持一致性，初始狀態如下圖所示：

 

 

 

 

1. 如果 Leader 節點向從節點廣播日志時，其中某個從節點發送故障宕機，該如何處理呢？

2. 日志在什么環節進行提交呢？Leader節點在收到客戶端的數據變更請求后，首先追加到主節點的日志文件中，然后廣播到從節點，從節點收到日志信息，是提交日志后返回ACK，還是什么時候提交呢？

3. 日志如何保證唯一。

4. 如何處理網絡出現分區。