Raft概述

Raft

1. 概述

Raft是一種一致性(共識)算法，相比Paxos，Raft更容易理解和實現，它將分佈式一致性問題分解成多個子問題，Leader選舉（Leader election）、日誌複製（Log replication）、安全性（Safety）、日誌壓縮（Log compaction）等。

1.1 角色

Raft中的角色分爲：

• Leader：接受客戶端請求，並向Follower同步請求日誌，當日志同步到大多數節點上後告訴Follower提交日誌。
• Follower：接受並持久化Leader同步的日誌，在Leader告之日誌能夠提交以後，提交日誌。
• Candidate：Leader選舉過程當中的臨時角色，即候選人。

Raft要求系統在任意時刻最多隻有一個Leader，正常工做期間只有Leader和Followers。Raft算法將時間分爲一個個的任期（term），每個term的開始都是Leader選舉。在成功選舉Leader以後，Leader會在整個term內管理整個集羣。若是Leader選舉失敗，該term就會由於沒有Leader而結束。

1.2 任期

Raft算法將時間分爲任意不一樣長度的任期（Term），用連續遞增的數字來表示。每一個任期都開始於選舉（election），一個或者多個Candidate（候選人）會試圖成爲領導者。若是一個候選人在該輪選舉得到了大多數投票（N/2 + 1），則將成爲該任期的領導者。在某些狀況下，選票可能會被瓜分，則該輪可能沒選出領導者，那麼將會開始另外一個任期，並進行下一次選舉。Raft算法保證在任意一個任期內，最多隻有一個領導者。

1.3 RPC

Raft算法中每一個服務器使用RPC（遠程過程調用）進行通訊，分爲如下三種。

• RequestVote RPC：候選人在選舉期間發起。
• AppendEntries RPC：領導人發起的一種心跳機制，複製日誌也在該命令中完成。
• InstallSnapshot RPC: 領導者使用該RPC來發送快照給太落後的追隨者。

2. 選舉

2.1 概述

當服務啓動時，每一個角色初始化爲follower，若是follower沒有接收到來自leader的heartbeat（心跳）,則將成爲候選者。候選人向其餘節點發送投票請求，其餘節點則進行答覆。當候選人得到大多數投票時，將成爲領導者。這個過程就叫作Leader Election。

請求投票 獲得大多數投票，成爲leader。

每個follower都有一個時鐘，是一個隨機的值，表示的是follower等待成爲candidate的時間，誰的時鐘先跑完，則發起leader選舉。

Follower將其當前term加一而後轉換爲Candidate。它首先給本身投票而且給集羣中的其餘服務器發送 RequestVote RPC。結果有如下三種狀況：

• 贏得了多數的選票，成功選舉爲Leader；
• 收到了Leader的消息，表示有其它服務器已經搶先當選了Leader；
• 沒有服務器贏得多數的選票，Leader選舉失敗，等待選舉時間超時後發起下一次選舉。

2.2 超時時間

Raft算法中有兩個超時時間，分別爲選舉超時（election timeout）和心跳超時（heartbeat timeout）。

選舉超時爲follower一直等待直到變爲candidate的總時間，此時間是隨機的，150ms~300ms，當時間走完，則follower變爲candidate，進行新一輪term的選舉。

它首先給本身投票而且給集羣中的其餘服務器發送 RequestVote RPC。若是接收到請求的node在本任期內還沒投票，則該node將給候選人投上一票，同時該node重置本身的election timeout。當候選人獲得大多數投票時，他將成爲領導者。leader將開始發送Append Entry給follower，這些消息按心跳超時指定的時間間隔發送。

follower會對這些信息進行response，即follower每接收到一條Append Entry，會進行一次response，如此循環。當任意一個follower中止接收到心跳併成爲候選人時，該任期結束。

2.3 Splite Vote

兩個node在同一個任期內發起選舉，且得到同數量的投票，此時沒法選舉出新的leader，那麼node將從新等待新一輪的選舉到來，因爲選舉超時是隨機的，因此兩個node再次同時發起選舉的概率就比較低，只有一個node成爲新的leader。

3. 日誌複製

客戶端與leader進行通訊，客戶端得請求到達leader後，leader生成日誌記錄（log entry），但此時log還未提交，故值未更改。

leader則嘗試發起AppendEntries rpc請求給follower，讓他們複製這條日誌，則leader將一直等待，直到大部分follower複製了這條日誌。這時候，這條日誌被提交，值被更改。而後leader再通知follower，這條日誌已經被提交，如今整個集羣得狀態是一致的。

3.1如何處理網絡分區

若是發生了網絡分區，此時系統會有兩個leader，分別爲任期1的Node B和任期3的Node E。此時若是有兩個客戶端，分別連上兩個leader。node E能提交，由於能達到大多數請求的回覆。因爲B沒法達到大多數請求的回覆，故客戶端的SET 3命令是未提交的。

而後網絡恢復，則node A和B將回滾未提交的日誌，與新的leader進行匹配。最終系統將一致。