運行3000次都不出錯的MIT6.824 Raft 實驗示例分析

運行3000次都不出錯的MIT6.824 Raft 實驗示例分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

前幾天在分布式系統交流群里，小伙伴們都在討論 6.824 的 raft 實驗批量測試 2000 次以上總會出錯，錯誤出在  Figure8Unreliable 和 UnreliableChurn2 這兩個測試。我自己其實也遇到了這個問題，這里記錄下我自己的解決思路。

能到這步，首先默認你的程序已經沒有大的問題，只是在上千次的測試中會有選舉不出來(活鎖問題)或提交的日志沖突問題。

上面兩個測試說白了，就是把網絡搞得很亂，寫一堆日志，然后給你 10 秒時間，沒選出新的 Leader 就會出錯。主要有兩種錯誤：failed to  reach agreement 或者 apply error

這兩個問題分別用下面兩種思路解決。

選舉超時不能隨便重置

如果仔細閱讀過 Students' Guide to Raft，其實里面很清楚寫著，選舉超時時間只能在下面三種情況下重置：

• 收到現任 Leader 的心跳請求，如果 AppendEntries 請求參數的任期是過期的(args.Term <  currentTerm)，不能重置;

• 節點開始了一次選舉;

• 節點投票給了別的節點(沒投的話也不能重置);

原文：

you should only restart your election timer if a) you get an AppendEntries  RPC from the current leader (i.e., if the term in the AppendEntries arguments is  outdated, you should not reset your timer); b) you are starting an election; or  c) you grant a vote to another peer.

這個問題其實很容易理解，主要容易錯在，代碼改著改著，就會不小心搞錯了選舉時間重置的位置，然后給后面的排查埋下了坑。

檢查一下你是否胡亂重置了這個時間，我和群里另一位小伙伴的問題就出現在第三種情況。

正確處理 rpc 響應

處理 rpc 響應的時候也要小心，收到 rpc 響應的時候，如果 currentTerm != args.Term 了，這次 rpc  就要丟掉不能用了。

當然，如果節點角色已經變了，那也要忽略掉這次 rpc 響應。

總結

調試這個問題主要是要細心，關注細節，多讀幾遍：https://thesquareplanet.com/blog/students-guide-to-raft/

進行批量測試的腳本在這里：https://gist.github.com/jonhoo/f686cacb4b9fe716d5aa

使用方法是：

./go-test-many.sh 測試次數 并行數(默認是 CPU 個數) 哪個測試

例如要測試 2C 這個測試 2000 次，并行 8 個測試。

./go-test-many.sh 2000 8 2C

又比如單獨測試 TestFigure8Unreliable2C 2000 次。

./go-test-many.sh 2000 8 TestFigure8Unreliable2C

看完上述內容，你們掌握運行3000次都不出錯的MIT6.824 Raft 實驗示例分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！