如何理解分布式一致性Raft協議

這篇文章主要介紹了如何理解分布式一致性Raft協議的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇如何理解分布式一致性Raft協議文章都會有所收獲，下面我們一起來看看吧。

什么是分布式一致性

下面舉個例子：

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

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

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

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

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

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

    

    

   

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

    

    

   

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

    

    

   

Leader選舉

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

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

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

日志復制流程

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

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

1. client 發送數據更改請求到Leader

    

    

   

2. Leader復制日志記錄到Follower節點

    

    

   

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

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

    

    

   

   image.png

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

6. Follower節點commit該日志記錄。

    

    

   

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

term選舉周期

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

timeout

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

選舉和選舉timeout

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

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

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

    

    

   

    

    

   

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

    

    

   

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

    

    

   

4. 一個選舉周期完成，接下來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節點發送日志記錄，并且需要確保所有的節點都能夠接受到完整的日志記錄。

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

    

    

   

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

    

    

   

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

    

    

關于“如何理解分布式一致性Raft協議”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“如何理解分布式一致性Raft協議”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。