raft算法學習記錄

分佈式系統中考慮得最多的一個問題：節點崩潰

• raft算法中節點分三類： leader、follower、candidate。
• 其中最複雜的問題都和leader節點崩潰有關，follower和candidate簡單直觀。

如何比較兩個節點的日誌條目，哪一個節點的日誌更加新？

• 任期大者，更新
• 任期相同者，index大者更新

leader日誌完整性特性(Leader Completeness Prop-erty)

leader日誌完整性特性的意思解讀：leader能當選，必須擁有完整日誌。這一特性保證了raft算法是安全的，任何一致性算法必須保證這一點。否則，意味着算法存在丟數據的漏洞。

論證過程的翻譯： 在5.4.3章節

三個關鍵時間

廣播時間（broadcastTime） << 選舉超時時間（electionTimeout） << 平均故障間隔時間（MTBF）

• 廣播時間指的是一個服務器並行地發送 RPCs 給集羣中全部的其餘服務器並接收到響應的平均時間；
• 選舉超時時間就是在 5.2節中介紹的選舉超時時間；
• 平均故障間隔時間就是對於一臺服務器而言，兩次故障間隔時間的平均值。

廣播時間必須比選舉超時時間小一個量級，選舉超時時間須要比平均故障間隔時間小上幾個數量級.

集羣成員變動問題

當集羣配置變動時，以日誌的方式來處理配置變動以後的各節點的最終一致。配置變動但未最終一致期間，若是leader結點崩潰，一樣遵循日誌同步的規則。即擁有配置變動日誌的結點纔可能當選爲leader。

還有三個問題要解決：

1. 新的服務器以沒有投票權身份加入到集羣中來（leader 也複製日誌給它們，可是考慮過半的時候不用考慮它們）。直到日誌完成同步到新的服務器。
2. 第二個問題是，集羣的 leader 可能不是新配置中的一員。這是一個很是極端的狀況，發生在新配置剛提交，可是未複製到大多數結點時，leader就崩潰了。這個時間新leader是個舊配置結點，它能夠處理客戶端的請求，可是一旦新配置日誌提交，新leader就會變成follower,集羣將從新進行選舉。
3. 第三個問題是，被移除的服務器會發起新選舉。這個好解決，執行下線的服務器程序上把rpc請求也關閉就ok了。

日誌量太大的問題引伸出日誌壓縮的需求

即 raft快照。

帶着問題去學習raft

• leader在什麼時機會將日誌提交給狀態機？
• follower如何確認本身的日誌是完整的？
• 除了隨機超時時間，還有什麼方法能夠避免candidate瓜分選票的問題？
• 只有一個領導人，單結點和性能問題如何解決？
• 新舊leader交接時，舊leader的日誌未提交，如何保證日誌完整？
• leader的日誌比follower還少，怎麼最終一致？
• raft不保證每一個結點按相同的順序執行全部日誌，那如何保證全部結點的狀態最終一致？
• 投票者是否能夠重複投票？如可不行，如何處理的？

開源實現sofa-jraft(java) braft(c++) edc/raft(go)