MIT 6.824 Lab2A Leader Election_mit6.824 lab2a 是有可能同时存在两个leader的-优快云博客

本文链接：https://blog.youkuaiyun.com/chunzhenwangluo/article/details/121188245

本文详述了MIT 6.824 Lab2A中关于Raft算法的领导者选举（Leader Election）和心跳（Heartbeats）的实现。实验目标是确保在集群中唯一且持久的领导者，并在领导者故障时迅速选举新的领导者。文中介绍了选举超时、发送心跳、RequestVote和AppendEntries等关键过程，并讨论了如何避免多个领导者的问题，同时提供了实验的代码实现和测试要求。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

实验准备

实验代码：git://g.csail.mit.edu/6.824-golabs-2021/src/raft
如何测试：go test -run 2A -race
相关论文：Raft Extended Section 5.2
实验指导：6.824 Lab 2: Raft (mit.edu)

实验目标

实现Raft算法中Leader Election（RequestVote RPC）和Heartbeats（AppendEntries RPC）。确保只有一个Leader被选中，且若无错误该Leader会一直唯一存在，当该Leader下线或发生其他错误导致发出的数据无法被成功接收，则会产生新的Leader来替代。

一些提示

参考论文的Figure 2实现相应的结构体和函数。
通过Make()创建一个后台goroutine，用于一段时间（election timeout）没收到其他节点的消息时，通过RequestVote RPC发起选举。
尽量保证不同节点的election timeout不会让他们在同一时间发起选举，避免所有节点只为自己投票，可以通过设置随机的election timeout来实现。
测试要求Hearbeats频率每秒不高于10次。
测试要求New Leader在Old Leader下线后5秒内出现，考虑到一次换届多轮选举的情况（提示3的情况），election timeout应当足够短。
论文中对于election timeout设定在150ms - 300ms之间，前提是Heartbeat频率远远超过150ms一次。由于提示4的限制，实验中election timeout应该更大。
推荐使用time.Sleep()而不是time.Timer或time.Ticker来实现定期或延迟行为。
不要忘记实现GetState()。
使用rf.killed()判断测试是否关闭了该节点。
RPC相关结构字段都应使用大写字母开头，这和Go语言的语法有关。