运行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 实验示例分析的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！