运行 3000 次都不出错的 MIT 6.824 Raft 实验

▲ 点击上方"多颗糖"关注公众号

大家好，最近忙着“大动作”（就快和大家见面了），更新频率低了一些，在此感谢没有取关的每个读者。

前几天在分布式系统交流群里，小伙伴们都在讨论 6.824 的 raft 实验批量测试 2000 次以上总会出错，错误出在 Figure8Unreliable 和 UnreliableChurn2 这两个测试。我自己其实也遇到了这个问题，这里记录下我自己的解决思路。

能到这步，首先默认你的程序已经没有大的问题，只是在上千次的测试中会有选举不出来（活锁问题）或提交的日志冲突问题。如果连单次测试都还过不去，请先移步《【MIT 6.824】学习笔记 5: 2021 Raft 实验实现细节》

上面两个测试说白了，就是把网络搞得很乱，写一堆日志，然后给你 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

相关阅读

【MIT 6.824】学习笔记 1：MapReduce

【MIT 6.824】学习笔记 2: RPC and Threads

【MIT 6.824】学习笔记 3: GFS

【MIT 6.824】学习笔记4: 主从复制(Primary/Backup Replication)

【MIT 6.824】学习笔记 5: 2021 Raft 实现细节

【MIT 6.824】学习笔记 6: ZooKeeper 设计原理

欢迎关注我的公众号：