共計 2299 個字符，預計需要花費 6 分鐘才能閱讀完成。

這篇文章主要介紹了如何理解分布式一致性 Raft 協議的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇如何理解分布式一致性 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 節點的數據。

image.png

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 提交該日志記錄。

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