6.824-lab2[仅完成2A]
; 1010 words
目录
快速开始
2A
2A主要实现领导选举和心跳检测功能，当领导出问题后，需要选举出新领导. 我们可以从测试逻辑入手分析，启动三个server，这里启动时会调用make逻辑，在make里通过ticker定期发起心跳检测【AppendEntries】。如果某个server没有收到心跳，则认为该server挂了，需要重新选举出新领导【RequestVote】。
- 初始状态：全部是follower
- 当follower一定时间未收到来自leader的心跳检测，认定目前没有有效leader，将自身状态转换为candidate，发起选举。这里不同节点的超时时间不同，避免多个节点同时发起选举而造成平票选举失败。
- 一旦节点获得多数票赢得选举，变成leader，开始发送心跳检测。
并发场景需要加锁，测试时使用-race可以检测数据竞争，修改后保证数据可用性。
2B
2b是关于日志Entry的同步，本质上是实现日志的同步与一致性校验。按照Hint所说
- 实现Start()接口，通过AppendEntries发送和接收日志Entry，并通过applyCh将新日志Entry发送给其他节点。
- 实现
election restriction。candidate发起选举时要有已committed的entry。
让我们逐步解析在2b里我们应该要做的事情：
AppendEntries:
在心跳检查中增加了对日志同步的校验，上一条日志的索引和term应该一致【Reply false if log doesn’t contain an entry at prevLogIndex whose term matches prevLogTerm】，确认一致后，follower对leader发送的log entry进行同步复制。
因此这里也包括 Leader 刚上任时的日志同步，Leader把所有 nextIndex 初始化为自己日志最后一条之后的索引，如果 Follower 的日志与 Leader 不一致，AppendEntries 的一致性检查会失败。Leader 会递减 nextIndex 并重试 AppendEntries，直到找到最大的一致的日志位置，leader开始向follower同步日志。
RequestVote:
发起选举里也包括了对candidate日志的校验，需要保证candidate的日志不是up-to-date[candidate’s log is at least as up-to-date as receiver’s log]。
对up-to-date的定义在5.4 Election restriction中，需要比较两个日志的最后一条条目： 如果 Term 不同 → Term 更大的日志更新；如果 Term 相同 → index更大的日志更新。
This is a page about »6.824_lab2«.