理解分布式一致性:Raft協議

• 什么是分布式一致性
• Leader選舉
• 日志復制流程
• term選舉周期
• timeout
• 選舉和選舉timeout
• 選舉分裂
• 日志復制和心跳timeout

在分布式系統中，分布式一致性是一個非常重要的概念，它是指分布式系統的各個服務器都保持一個統一的狀態（數據）。但是在分布式系統中，通常由于網絡，系統狀態等原因會導致某些服務不可用或者不可靠。這就需要一種分布式一致性的協議來保證系統在某些服務失敗的情況下仍然整體可用。

Raft協議是受到Paxos的影響而產生的，相對于Paxos而言，Raft協議更加簡單易懂。我會在后面的博客里面專門詳細介紹Paxos協議的具體內容。這里我們重點討論Raft協議。

什么是分布式一致性

下面舉個例子：

假如我們有一個單節點的服務節點A，這個單節點的服務只是用來存儲一個字母。同時我們還有一個客戶端向這個服務發起更新數據的請求。

對于單節點的分布式一致性來說，服務響應客戶端的更新請求即可。但是當我們有多個服務節點的情況下會怎么樣呢？

Raft協議就是保證多個服務器節點數據一致性的協議。

接下來我們看看Raft是怎么工作的。

Raft協議中，一個服務器的節點可以是以下三種狀態中的任意一個：

Follower 狀態：跟隨者，被動接收數據。我們用實心圓表示。

Candidate 狀態：候選人，可以被選做Leader。我們用實心圓+虛線邊框表示。

Leader 狀態：領導者，處理所有客戶端交互，日志復制等，一般一次只有一個Leader. 我們用實心圓+實線邊框表示。

Leader選舉

所有的節點都是從Follower狀態開始的。

如果Follower在一定的時間里面沒有收到選舉請求或者Leader節點的回復，Follower則會轉變為Candidate。

Candidate會發送選舉請求給所有的其他節點，收到選舉請求的其他節點會反饋回Candidate，當Candidate收到的所有響應數目大于n/2 時，Candidate會認為絕大多數節點已經選我作為Leader了，這時候Candidate就會轉變為Leader。接下來所有的數據變化都會經由Leader發起。

日志復制流程

在Raft系統中，所有的數據變化都是以日志記錄的形式添加到服務節點之中。服務節點會不斷的讀取日志記錄，并將日志記錄更新到服務節點的數據中。日志記錄最開始的狀態是uncommited, 更新之后狀態則變為commited.

為了實現所有服務節點的一致性更新，步驟如下：

client 發送數據更改請求到Leader

Leader復制日志記錄到Follower節點

Leader等待大多數節點完成復制日志記錄。

Leader節點commit 當前日志記錄，并更新Leader節點的數據。

Leader通知Follower節點該日志記錄已經commit.

Follower節點commit該日志記錄。

整個分布式系統實現了數據一致性。

term選舉周期

在Raft 協議中，有一個term的概念。term是一個選舉周期，一個term周期只會產生一個Leader，term連續遞增。

timeout

在Raft協議中，為了保證選舉和數據更新的順利進行，規定了兩種類型的timeout:
選舉timeout和心跳timeout。

選舉和選舉timeout

每個term開始時，會重置選舉timeout。在一個term中，Follower會等待timeout的時間，如果超出這個時間還沒有得到其他節點的選舉請求，Follower會主動轉變為Candidate，并且term+1，意味著開啟了新的選舉周期。

選舉timeout是150ms-300ms之間的一個隨機數，之所以隨機產生timeout，是為了避免同時產生多個Candidate的情況。

當Follower轉變為Candidate之后，term加1， 然后開始新一輪的選舉。Candidate首先會將自己的Vote Count 加1，然后發送請求選舉的消息給其他節點。

接收節點首先會比較term的大小，如果自己的term小于Candidate的term，則更新自己的term和Candidate的term保持一致，并重置timeout。如果接收節點在這個term中還沒有做任何選舉，則會返回選舉響應消息給Candidate節點。

Candidate 節點收到大部分節點的選舉響應之后，會變成Leader 節點。

一個選舉周期完成，接下來Leader 發送更新日志給Follower節點，進入日志更新階段。

選舉分裂

值得注意的是Candidate只有得到超出n/2個節點的選舉響應才能變為Leader節點。如果兩個Follower節點同時變成Candidate節點，則會產生選舉分裂的問題。
現在假設我們總共有4個節點，其中兩個節點同時變成Candidate節點，并向其余兩個節點發送選舉請求：

節點B，C成為Candidate節點并行向節點A，D發送選舉請求。
節點A，D分別響應節點B，C的請求，這時候兩個Candidate節點由于得到的Vote都是2，不滿足大于n/2的條件，則其不能轉變為Leader節點，繼續等待timeout至新的term開始并開啟新一輪的選舉，只到符合條件為止。

日志復制和心跳timeout

當系統進入到日志復制階段，Leader節點會以心跳timeout的節奏向Follower節點發送日志記錄，并且需要確保所有的節點都能夠接受到完整的日志記錄。

客戶發送set 5 給Leader， 在下一個心跳timeout，Leader將set 5的日志記錄發給Follower。

Leader 收到大部分節點的ack 響應之后，commit 該日志記錄。

Leader通知Client已經提交該日志記錄，同時通知Follower 提交該日志記錄。

更多精彩內容且看：

• 區塊鏈從入門到放棄系列教程-涵蓋密碼學,超級賬本,以太坊,Libra,比特幣等持續更新
• Spring Boot 2.X系列教程:七天從無到有掌握Spring Boot-持續更新
• Spring 5.X系列教程:滿足你對Spring5的一切想象-持續更新
• java程序員從小工到專家成神之路（2020版）-持續更新中,附詳細文章教程

更多教程請參考flydean的博客

總結

以上是生活随笔為你收集整理的理解分布式一致性:Raft协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。