分布式一致性

想象一下，我們有一個單節點系統，且作為數據庫服務器，然后存儲了一個值（假設為X）。然后，有一個客戶端往服務器發送了一個值（假設為8）。只要服務器接受到這個值即可，這個值在單節點上的一致性非常容易保證：

image

但是，如果數據庫服務器有多個節點呢？比如，如下圖所示，有三個節點：a，b，c。這時候客戶端對這個由3個節點組成的數據庫集群進行操作時的值一致性如何保證，這就是分布式一致性問題。而Raft就是一種實現了分布式一致性的協議（還有其他一些一致性算法，例如：ZAB、PAXOS等）：

image

一些概念

講解Raft算法之前，先普及一些Raft協議涉及到的概念：
term：任期，比如新的選舉任期，即整個集群初始化時，或者新的Leader選舉就會開始一個新的選舉任期。
大多數：假設一個集群由N個節點組成，那么大多數就是至少N/2+1。例如：3個節點的集群，大多數就是至少2；5個節點的集群，大多數就是至少3。
狀態：每個節點有三種狀態，且某一時刻只能是三種狀態中的一種：Follower（圖左），Candidate（圖中），Leader（圖右）。假設三種狀態不同圖案如下所示：

image

初始化狀態時，三個節點都是Follower狀態，并且term為0，如下圖所示：

image

Leader選舉

Leader選舉需要某個節點發起投票，在確定哪個節點向其他節點發起投票之前，每個節點會分配一個隨機的選舉超時時間（election timeout）。在這個時間內，節點必須等待，不能成為Candidate狀態。現在假設節點a等待168ms , 節點b等待210ms , 節點c等待200ms 。由于a的等待時間最短，所以它會最先成為Candidate，并向另外兩個節點發起投票請求，希望它們能選舉自己為Leader：

image

另外兩個節點收到請求后，假設將它們的投票返回給Candidate狀態節點a，節點a由于得到了大多數節點的投票，就會從Candidate變為Leader，如下圖所示，這個過程就叫做Leader選舉（Leader Election）。接下來，這個分布式系統所有的改變都要先經過節點a，即Leader節點：

image

如果某個時刻，Follower不再收到Leader的消息，它就會變成Candidate。然后請求其他節點給他投票（類似拉票一樣）。其他節點就會回復它投票結果，如果它能得到大多數節點的投票，它就能成為新的Leader。

日志復制

假設接下來客戶端發起一個SET 5的請求，這個請求會首先由leader即節點a接收到，并且節點a寫入一條日志。由于這條日志還沒被其他任何節點接收，所以它的狀態是uncommitted。

image

為了提交這條日志，Leader會將這條日志通過心跳消息復制給其他的Follower節點：

image

一旦有大多數節點成功寫入這條日志，那么Leader節點的這條日志狀態就會更新為committed狀態，并且值更新為5：

image

Leader節點然后通知其他Follower節點，其他節點也會將值更新為5。如下圖所示，這個時候集群的狀態是完全一致的，這個過程就叫做日志復制（Log Replication）：

image

兩個超時

接下來介紹Raft中兩個很重要的超時設置：選舉超時和心跳超時。

• 選舉超時

為了防止3個節點（假設集群由3個節點組成）同時發起投票，會給每個節點分配一個隨機的選舉超時時間（Election Timeout），即從Follower狀態成為Candidate狀態需要等待的時間。在這個時間內，節點必須等待，不能成為Candidate狀態。如下圖所示，節點C優先成為Candidate，而節點A和B還在等待中：

image

• 心跳超時

如下圖所示，節點A和C投票給了B，所以節點B是leader節點。節點B會固定間隔時間向兩個Follower節點A和C發送心跳消息，這個固定間隔時間被稱為heartbeat timeout。Follower節點收到每一條日志信息都需要向Leader節點響應這條日志復制的結果：

image

重新選舉

選舉過程中，如果Leader節點出現故障，就會觸發重新選舉。如下圖所示，Leader節點B故障（灰色），這時候節點A和C就會等待一個隨機時間（選舉超時），誰等待的時候更短，誰就先成為Candidate，然后向其他節點發送投票請求：

image

如果節點A能得得到節點C的投票，加上自己的投票，就有大多數選票。那么節點A將成為新的Leader節點，并且Term即任期的值加1更新到2：

image

需要說明的是，每個選舉期只會選出一個Leader。假設同一時間有兩個節點成為Candidate（它們隨機等待選舉超時時間剛好一樣），如下圖所示，并且假設節點A收到了節點B的投票，而節點C收到了節點D的投票：

image

這種情況下，就會觸發一次新的選舉，節點A和節點B又等待一個隨機的選舉超時時間，直到一方勝出：

image

我們假設節點A能得到大多數投票，那么接下來節點A就會成為新的Leader節點，并且任期term加1：

image

網絡分區

在發生網絡分區的時候，Raft一樣能保持一致性。如下圖所示，假設我們的集群由5個節點組成，且節點B是Leader節點：

image

我們假設發生了網絡分區：節點A和B在一個網絡分區，節點C、D和E在另一個網絡分區，如下圖所示，且節點B和節點C分別是兩個網絡分區中的Leader節點：

image

我們假設還有一個客戶端，并且往節點B上發送了一個SET 3，由于網絡分區的原因，這個值不能被另一個網絡分區中的Leader即節點C拿到，它最多只能被兩個節點（節點B和C）感知到，所以它的狀態是uncomitted（紅色）：

image

另一個客戶端準備執行SET 8的操作，由于可以被同一個分區下總計三個節點（節點C、D和E）感知到，3個節點已經符合大多數節點的條件。所以，這個值的狀態就是committed：

image

接下來，我們假設網絡恢復正常，如下圖所示。節點B能感知到C節點這個Leader的存在，它就會從Leader狀態退回到Follower狀態，并且節點A和B會回滾之前沒有提交的日志（SET 3產生的uncommitted日志）。同時，節點A和B會從新的Leader節點即C節點獲取最新的日志（SET 8產生的日志），從而將它們的值更新為8。如此以來，整個集群的5個節點數據完全一致了：

image