mit6.824 lab2 RAFT leaderElection 要点记录

我的6.824 课程 Pass，欢迎STAR

task1 LeaderElection：

• 一个raft节点，要有计时的装置，另外一个是要有处理外部的请求。对于RequestVote，需要是并行分发，变成leader以后，进行新的HB维持关系。

• candidate在进行等待vote的时候，如果收到来自leader 的AE（在进行判断了以后），需要退到follower或者继续candidate，这个问题在于如何同时的做这两件事，两个goroutines 如何做到沟通。我在这里的实现是通过raft内部设置一个AENotification channel来解决的。当这个channel中有消息时，就意味着收到了其他node的AE消息，然后判断自己还是不是leader，不是leader就退出leader过程

• 选举超时的选择：256-512ms的区间，考虑到选举超时应该远远大于RTT，这里因为labrpc的限制 1s 内最多10个HB，模拟的是长延时环境下的election 过程。但也要太大，5s要选出来。

• **整体的设计思路：在mainProcess中，三个角色循环变化。每一个角色都会监听时间变化，通过select进行多操作的同时进行。candidate并行分发RV，同时监听AE的channel，并且开始时设置选举超时，这个地方使用SELECT进行监听，两个情况：1. AE先来，然后退到follower阶段。2. RV true大于(n-1)/2先来，然后就成为LEADER。如果RV没有接收到来follower的RVR，就需要重新发送，这个时候，如果已经变成leader，那么就不在发送；leader 进行AE(HB)的操作，与follower进行沟通；follower没有明显的动作，超时会进入下一次的选举。**论文中要求刚开始的时候等待一个Election timeout时间，然后才开始进行ELECtion 选举。这样相对于我的一开始就进行选举类似。

问题：

1. Term的超时与计时：对于follower计时是从受到AE的时候开始，超时也同样，所以收到AE就要跳出选举阶段的Select，对于follower没有别的过多的动作，只需要等到TermTimeOut就行，相应的操作由来自leader的RPC调用来完成。

2. 选举阶段收到AE以后：candidate的动作：判断是否符合要求，符合条件关闭接收RVR的chan，然后把leaderNum设置一下为candidate的ID或者-1，退到follower的状态。每次leader的AE来了就把选举超时的计时重置。

3. 在成为Leader以后，设置一个Term长度的定时器，等到Term时间结束就放弃身份。由leader主动放弃，follower在ElectionTimeout时间内没有收到的情况下就转到candidate状态。

4. 文章第4页的图中，RPC返回消息中，都没有添加自己的ID，我觉得需要添加一个ID，因为需要一个来使leader更新自己对于follower状态的一个消息。(文章只是给了很基础的结构，很多东西都需要自己去完善)

5. 一个term内最多只能vote one node。如果本身是candidate并且对方的log比自己的新，这时候是可以在vote给别人的。

6. AE中在对preLogIndex进行查询的时候，是一个O(n)的操作，考虑到RAFT是时间敏感的，这里应该使用快速的算法查找存在性。

7. AE的判断与处理是一个相对来说比较复杂的部分，多个条件需要判断

If the logs have last entries with different terms, then the log with the later term is more up-to-date. If the logs end with the same term, then whichever log is longer is more up-to-date. 文章第8页

LAB2 的task2 log replication
LAB2 的task3 node persist