raft協議,leader在commit了一條日誌後,立刻掛了,那其他節點如何處理這條日誌?

時間 2021-05-30 00:13:12

1樓:王傳義

該問題問的非常好,

首先故障傳送後,raft不會通過簡單計數判斷是否安全寫入,這也你是有疑問地方。

不管log 日誌處於什麼狀態。總能保證內部資料的一致性。具體是寫入還是覆蓋。

要看具體情況。但是對客戶端不清楚的,需要客戶做冪等操作等處理。

問題:怎麼保證一致性的。

依然通過正常日誌複製操作(這地方沒有做什麼複雜處理)

2樓:

如果leader僅僅更新自己的commitIndex=N後,沒有將follower的commitIndex更新為N(也就是實際上,=N,index=N的這條日誌才算作被提交。因為此時即使leader掛掉,新一輪選出的leader,必然是commitIndex=N的follower。

實際raft系統實現過程中,如果關心系統到底提交到了哪條日誌,可以根據實際情況返回結果:1、如果沒那麼嚴格,可以直接返回leader的commitIndex。除了上述特殊情況以及另乙個特殊情況,結果都是準確的 2、如果偏保守,可以返回leader的commitIndex-1。

3、如果非要準確的結果,可能要增加系統的複雜性了。

3樓:mwish

Commit 一定是 1/2 以上的機器有這條日誌的

選舉的安全限制會讓這一半的機器不會給沒有的投票

新的 Leader 在集群可用的情況下一定有這條日誌(畢竟 Log 需要持久化),它發現半數以上有這條日誌後會 Commit

4樓:RHorizon

raft演算法中,是leader發出commit命令,要求從節點commit一條日誌記錄,並且在大部分節點commit成功後,leader才會執行commit命令。題主的描述中,如果leader在commit一條日誌成功後,掛掉了,那剩下的機器中肯定有半數以上的機器已經commit了這條日誌,在下次選舉的時候,也肯定可以選出已經commit了這條日誌的機器做leader,新的leader會把這條日誌同步給未commit的機器。

5樓:無名

關鍵原因commit的資料已經寫入多數派,而任意多數派一定會有交集

candidate被多數派投票成功才能成為新leader,說明一定拿到了commit時寫入的那個多數派至少乙個節點的認可,這說明新leader的日誌比那個節點更全。

在raft裡,具體就是使用新的term提交一條no-op,來促成標題提到的那條日誌被commit。

6樓:Thearas

被 leader commit 證明至少已經有 n / 2 + 1 的節點有這個 log entry 了,下一任 leader 也肯定會從這 n / 2 + 1 的節點中誕生(見補充),新 leader 會把 log entry 重新複製給各個 follower。

補充:因為沒有這個 log entry 的節點不會得到這 n / 2 + 1 中的任何節點的投票(你比我還小,我幹嘛投給你),得不到多數派的支援,當不上 leader。

7樓:祥光

首先,Raft在Leader選舉的時候保證擁有最新的已提交的log entry的Follower才有資格成為Leader。

新Leader通過強制Followers複製它的日誌來處理日誌的不一致,Followers上的不一致的日誌會被Leader的日誌覆蓋。

Leader為了使Followers的日誌同自己的一致,Leader需要找到Followers同它的日誌一致的地方,然後覆蓋Followers在該位置之後的條目。

參考Raft演算法詳解

8樓:

放進commited log中:Raft中不存在committed log,而是每個節點維護乙個commitIndex,這個commitIndex是volatile的,僅表示現在這個節點的commit位置

日誌的一致性是怎麼保證的:領導人完全性(Leader Completeness)要求如果某個日誌條目在某個term中已經被提交,那麼這個條目必然出現在所有具有更大的term的Leader中。因此不具備該entry的節點不可能被選舉為新leader

9樓:花半樓

核心在於要理解每個server持久化和非持久化物件。

因為,commit index只表示位置,其並不代表commit index之後的log沒有持久化。

所以,問題的核心還是在於term,voted for,log的持久化,其他的各種index都是通過這三個持久化物件算出來的。

回到你的問題,這條日誌一定會被後續leader commit。原因就在於後續選leader比較的是各server從自身持久化的log中計算出來的last log index 和last log term,和commit index沒啥關係。而顯然,舊leader 最後commit的那條log已經被其他server持久化了。

我的raft實現教程:

10樓:htner

領導人完全原則:如果乙個日誌條目在乙個給定任期內被提交,那麼這個條目一定會出現在所有任期號更大的領導人中

這條日誌一定會出現在新主的log上面。像Tianbing所說,commit index只是乙個位置,新主在它的任期提交一條日誌條目,會將這條前任的日誌一併提交的。

領導人完全原則(Leader Completeness Property)保證了領導人一定擁有所有已經被提交的日誌條目,但是在它任期開始的時候,它可能不知道哪些是已經被提交的。為了知道這些資訊,它需要在它的任期裡提交一條日誌條目。

11樓:藍色麻雀

新選出的leader,會在成為主節點後立即傳送的心跳通知做不一致的日誌截斷操作,並在後續的新任期內的日誌提交過程,順帶著也提交了上一任期的日誌。遵循的原則是:最新任期日誌提交意味著前一任期的日誌一定提交。

raft協議疑問?

bluebore 1.不能返回失敗 2.操作結果就是不可預知 呼叫者通過重試或者通過其他查詢手段獲取結果,具體到raft,就是重新更新一次或者發起一次一致性讀來確認到底有沒有寫成功。分布式系統中的請求結果區別與單機系統,最大的特點是存在 三態 的概念。也就是除了 成功 失敗 之外還有個 超時 未知 ...

raft協議和zab協議有啥區別?

CatKang 可以從以下幾個方向比較協議 primary backup system or state machine system raft是state machine system,zab是primary backup system 處理唯讀請求 raft的讀請求與寫請求處理邏輯一樣,zab用...

別再懷疑自己的智商了,Raft協議本來就不好理解

講理的乖乖女孩 不是推廣,看有個人回答真的像打廣告 我只是說像,別噴我。買了一瓶春紀新出的提亮精華,就是這個 我是暗黃皮,很容易曬黑,雖然本來也不白,假期用了這個,大概是夏天覺得上臉很不舒服,還便宜,就擦胳膊和手,當手部精華用的,真的白了!真的!開心死了,我是手超級超級黑的人,沒對比圖,因為沒照,用...