raft協議的重要知識點有哪些

這篇文章主要介紹了raft協議的重要知識點有哪些的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇raft協議的重要知識點有哪些文章都會有所收獲，下面我們一起來看看吧。

raft 協議是一致性協議中相對容易理解的一個實現，類似的還有zab，paxos等一致性算法。etcd是基于raft協議的，k8s依賴于etcd。

1,Raft算法的節點數量問題

Raft協議中主節點心跳失效后follower成為candidate并且在n/2個節點投票成為主節點，在RAFT協議集群中如何確認n是多少？動態增加機器如何變化n，超時多久應該認為節點為n-1?n固定好是動態調整好？

領導人選舉、日志復制、安全性的討論都是基于Raft集群成員恒定不變的，然而在很多時候，集群的節點可能需要進行維護，或者是因為需要擴容，那么就難以避免的需要向Raft集群中添加和刪除節點。最簡單的方式就是停止整個集群，更改集群的靜態配置，然后重新啟動集群，但是這樣就喪失了集群的可用性，往往是不可取的，所以Raft提供了兩種在不停機的情況下，動態的更改集群成員的方式：

單節點成員變更：One Server ConfChange

多節點聯合共識：Joint Consensus

從Cold遷移到Cnew的過程中，因為各個節點收到最新配置的實際不一樣，那么肯能導致在同一任期下多個Leader同時存在。

為了解決上面的問題，在集群成員變更的時候需要作出一些限定。

單節點成員變更

所謂單節點成員變更，就是每次只想集群中添加或移除一個節點。比如說以前集群中存在三個節點，現在需要將集群拓展為五個節點，那么就需要一個一個節點的添加，而不是一次添加兩個節點。

這個為什么安全呢？很容易枚舉出所有情況，原有集群奇偶數節點情況下，分別添加和刪除一個節點。在下圖中可以看出，如果每次只增加和刪除一個節點，那么Cold的Majority和Cnew的Majority之間一定存在交集，也就說是在同一個Term中，Cold和Cnew中交集的那一個節點只會進行一次投票，要么投票給Cold，要么投票給Cnew，這樣就避免了同一Term下出現兩個Leader。

變更的流程如下：

向Leader提交一個成員變更請求，請求的內容為服務節點的是添加還是移除，以及服務節點的地址信息

Leader在收到請求以后，回向日志中追加一條ConfChange的日志，其中包含了Cnew，后續這些日志會隨著AppendEntries的RPC同步所有的Follower節點中

當ConfChange的日志被添加到日志中是立即生效（注意：不是等到提交以后才生效）

當ConfChange的日志被復制到Cnew的Majority服務器上時，那么就可以對日志進行提交了

以上就是整個單節點的變更流程，在日志被提交以后，那么就可以：

馬上響應客戶端，變更已經完成

如果變更過程中移除了服務器，那么服務器可以關機了

可以開始下一輪的成員變更了，注意在上一次變更沒有結束之前，是不允許開始下一次變更的

可用性

可用性問題

在我們向集群添加或者刪除一個節點以后，可能會導致服務的不可用，比如向一個有三個節點的集群中添加一個干凈的，沒有任何日志的新節點，在添加節點以后，原集群中的一個Follower宕機了，那么此時集群中還有三個節點可用，滿足Majority，但是因為其中新加入的節點是干凈的，沒有任何日志的節點，需要花時間追趕最新的日志，所以在新節點追趕日志期間，整個服務是不可用的。

2，客戶端交互

包括客戶端如何發現領導人和 Raft 是如何支持線性化語義的

Raft 中的客戶端發送所有請求給領導人。當客戶端啟動的時候，他會隨機挑選一個服務器進行通信。如果客戶端第一次挑選的服務器不是領導人，那么那個服務器會拒絕客戶端的請求并且提供他最近接收到的領導人的信息（附加條目請求包含了領導人的網絡地址）。如果領導人已經崩潰了，那么客戶端的請求就會超時；客戶端之后會再次重試隨機挑選服務器的過程。

我們 Raft 的目標是要實現線性化語義（每一次操作立即執行，只執行一次，在他調用和收到回復之間）。但是，如上述，Raft 是可以執行同一條命令多次的：例如，如果領導人在提交了這條日志之后，但是在響應客戶端之前崩潰了，那么客戶端會和新的領導人重試這條指令，導致這條命令就被再次執行了。解決方案就是客戶端對于每一條指令都賦予一個唯一的序列號。然后，狀態機跟蹤每條指令最新的序列號和相應的響應。如果接收到一條指令，它的序列號已經被執行了，那么就立即返回結果，而不重新執行指令。

3，領導人選舉

Raft中的節點有三種狀態：

領導人狀態：Leader

跟隨者狀態：Follower

候選人狀態：Candidate

每一個節點都是一個狀態機，Raft會根據當前的心跳，任期等狀態來進行狀態的遷移轉化

首先，在Raft節點啟動的時候，所有任務都是Follower狀態， 因為此時沒有Leader，所有Follower都在固定的超時時間內都收不到來自Leader的心跳，從而變成了Candidate狀態，開始選舉Leader

當節點處于Candidate狀態的時候，會并發的向所有的節點發出請求投票請求RequestVote（后面章節會向詳細介紹），在Candidate狀態下，節點可能會發生三種狀態的遷移變化：

開始下一輪新的選舉：發出的投票請求在固定時間內沒有收到其他節點的響應，或者是收到響應（或者同意投票）的節點數量沒有達到 N/2+1，那么選取超時，進入下一輪選舉

選舉成功，成為新的Leader：如果選舉過程中收到大于N/2+1數量的節點的投票，那么選舉成功，當前的節點成為新的Leader

成為Follower：如果選舉過程中收到來及其他節點的Leader心跳，或者是請求投票響應的Term大于當前的節點Term，那么說明有新任期的Leader

如果節點選舉成功，成為了Leader，那么Leader將會在固定周期內發送心跳到所有的節點，但是如果心跳請求收到的響應的Term大于當前節點的Term，那么當前節點的就會成為Follower。比如Leader節點的網絡不穩定，掉線了一段時間，網絡恢復的時候，肯定有其他節點被選為了新的Leader，但是當前節點在掉線的時候并沒有發現其他節點選為Leader，仍然發送心跳給其他節點，其他節點就會把當前的新的Term響應給已經過時的Leader，從而轉變成Follower

4，日志復制

領導人必須從客戶端接收日志然后復制到集群中的其他節點，并且強制要求其他節點的日志保持和自己相同。

復制狀態機通常都是基于復制日志實現的，每一個服務器存儲一個包含一系列指令的日志，并且按照日志的順序進行執行。

客戶端請求服務器，請求的信息就是一系列的指明，比如PUT KEY VALUE

服務器在收到請求以后，將操作指令同步到所有的服務器中

服務器收到同步的指令以后，就將指令應用到狀態機中

最后響應客戶端操作成功

5，節點超時機制

每個節點都有150～300ms的隨機超時，如果收到leader的心跳包，會重新計時，否則將自己狀態設置為candidate，發起投票。由于時間是隨機的，減少了同時發起投票的可能性。follower是通過節點超時機制知道leader存活的，否則可能認為leader已經死亡。

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