raft協議問題

2021-09-18 05:54:27 字數 959 閱讀 6682

角色

raft通過選舉leader並由leader節點負責管理日誌複製來實現多副本的一致性。

在raft中,節點有三種角色:

角色轉換如下圖所示:

節點的狀態時通過心跳包來進行維持的。

產生的原因:

如果乙個follower在election timeout的時間裡沒有收到leader的資訊,就進入新的term,轉成candidate,給自己投票,發起選舉 requestvote rpc. 這個狀態持續到發生下面三個中的任意事件:

它贏得選舉

另外有server獲得選舉

1個term過去了,還是沒有選舉結果

為什麼會有3這個情況呢,前兩個很好理解,說一下第三個產生的原因,當如果大家同時發起選舉,都投給自己,那就沒有節點能夠得到多數選票了,這個時候就要進入下乙個term,再選一次,如果每次的election time的時間相同就會陷入死迴圈。 為了避免這個情況持續發生,每個server的election time被隨機的設成不同的值,所以先timeout的就可以先發起下一次選舉。

raft 演算法使用隨機選舉超時時間的方法來確保很少會發生選票瓜分的情況,就算發生也能很快的解決。因為超時時間相同的話,一旦兩個candidate選舉發生選票瓜分情況而無法選出leader,並且後續也很可能繼續發生選票瓜分。影響raft的正常執行。而隨機時間是最簡單也最容易理解的解決方式。

動畫演示:

選好leader之後就可以分發log啦.

每乙個log都有乙個log index 和 term number。當大多數的follower都複製好這個log時,就說這個log是committed,可以執行了。 leader 記住已經commit的最大log index, 用它來分發下乙個 rpc。 這個和tcp裡段的編號的作用是一樣的。

Raft協議介紹(翻譯)

本文討論的的raft一致性演算法來自於 in search of an understandable consensus algorithm.所有的引用都出自這篇文章.raft 是乙個分布式一致性演算法,它的設計很容易被理解。raft演算法解決了即使在出現故障時,多個伺服器同意同乙個共享狀態的問題。...

raft協議學習記錄

在b階段,s1下線,s5上線並被選為leader,同時寫入term3 index2,此時s1和s2中的entry仍然是term2 index2。此時在多個例項中已經存在不同的entry,根據raft的定義,將來一定會有例項的entry被另乙個 成為leader 例項的entry所覆蓋。因此需要一條額...

Raft 協議學習筆記

分布式儲存系統通常通過維護多個副本來進行容錯,提高系統的可用性。這就必須要解決分布式儲存系統的最核心問題 維護多個副本的一致性。一致性 consensus 是構建具有容錯性 fault tolerant 的分布式系統的基礎。在乙個具有一致性性質的的集群裡,同一時刻所有節點中的資料有相同的值。集群具有...