RocketMQ 多副本前置篇初探raft協議

raft協議是分布式領域解決一致性的又一著名協議，主要包含leader選舉、日誌複製兩個部分。

目錄2、日誌複製

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

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

通常情況下，三個節點中會有乙個節點的計時器率先到期，節點狀態變為 candidate ，候選者狀態下的節點會發起選舉投票。我們先來考慮只有乙個節點變為candidate時是如何進行選主的。

當節點狀態為candidate，將發起一輪投票，由於是第一輪投票，設定本輪投票輪次為1，並首先為自己投上一票，正如上圖所示的nodea節點，team為1，vote count為1.

當乙個節點的定時器超時後，首先為自己投上一票，然後向該組內其他的節點發起投票(用拉票更加合適)，傳送投票請求。

當集群內的節點收到投票請求外，如果本輪未進行過投票，則贊同，否則反對，然後將結果返回，並重置計時器。

當節點a收到的贊同票大於一半時，則公升級為該集群的 leader，然後定時向集群內的其他節點傳送心跳，以便確定自己的領導地位，正如下圖所示。

node a，集群中的 leader正在向其他節點傳送心跳包。

節點在收到 leader 的心跳包後，返回響應結果，並重置自身的計時器，如果 flower 狀態的節點在計時時間超時內沒有收到leader 的心跳包，就會從 flower 節點變成 candidate,該節點就會發起下一輪投票。

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

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

節點狀態

需要引入3中節點狀態：follower(跟隨者)、candidate(候選者)，投票的觸發點，leader(主節點)。

進入投票狀態的計時器

follower、candidate 兩個狀態時，需要維護乙個計時器，每次定時時間從150ms-300ms之間進行隨機，即每個節點的每次的計時過期不一樣，follower狀態時，計時器到點後，觸發一輪投票。節點在收到投票請求、leader 的心跳請求並作出響應後需要重置定時器。

投票輪次team

candidate 狀態的節點，每發起一輪投票，term 加一；term的儲存。

投票機制

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

成為leader的條件

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

完成集群內的選主工作後，客戶端向主節點傳送請求，由主節點負責資料的複製，使集群內的資料保持一致性，初始狀態如下圖所示：

客戶端向主節點發起請求，例如set 5，將資料更新為5，如下圖所示：

主節點收到客戶端請求後，將資料追加到leader的日誌中(但未提交)，然後在下乙個心跳包中將日誌**到集群內從節點，如下圖所示：

從節點收到leader的日誌後，追加到從節點的日誌檔案中，並返回確認ack。leader收到從節點的確認資訊後，向客戶端傳送確認資訊。

上述的日誌複製比較簡單，是由於只考慮正常的情況，如果中間發生異常，該如何保證資料一致性呢？

如果 leader 節點向從節點廣播日誌時，其中某個從節點傳送故障宕機，該如何處理呢？

日誌在什麼環節進行提交呢？leader節點在收到客戶端的資料變更請求後，首先追加到主節點的日誌檔案中，然後廣播到從節點，從節點收到日誌資訊，是提交日誌後返回ack，還是什麼時候提交呢？

日誌如何保證唯一。

如何處理網路出現分割槽。

我相信讀者朋友肯定還有更多的疑問，本文不打算來回答上述疑問，而是帶著這些問題進入到rocketmq多副本的學習中，通過原始碼分析rocketmq dledger的實現後，再來重新總結raft協議。

RocketMQ 多副本前置篇 初探raft協議