MIT6.824 spring21 Lab3A总结记录
写在前面
lab3A也完成了，前前后后也改了几版才改成现在的样子。
老规矩，记录一下设计思路。
代码见：https://github.com/sun-lingyu/MIT6.824-spring21/tree/KV-3A
代码结构
由于client的处理逻辑很简单，这里略去。
整体逻辑如上图。（图中的hreply是一个struct；h表示handler）
使用一个专门的applyListener goroutine监听applyCh。所有对KV状态的修改均由applyListener 进行。
当leader接受到RPC请求时：RPC Handler会先执行rf.start，将请求放入raft log。然后RPC Handler将等待raft达成共识，等待applyListener完成相应的状态修改/查询，然后返回reply。
图中没有画出来的：leader需要维护两个map：
1.pendingChannels：以log index为key，以hreply channel为value。每一个在leader处，已经执行了start，并且正在等待raft达成共识的RPC handler，都有一个与start返回的index相对应的channel。这是为了applyListener能够与RPC handler通信。
2. pendingMap：以log index为key，以Op为value。每一个在leader处，已经执行了start，并且正在等待raft达成共识的RPC handler，都有一个与start返回的index相对应的Op。这是为了applyListener能够进行duplicate detection。
当applyListener从applyCh收到了一个Op，它首先执行duplicate detection。
接下来，若这个Op不重复，且是PutAppend，则修改KV状态。
接下来，若它发现：这个Op的log index在其维护的pendingChannels和pendingMap中有相应的value，这就代表有相应的RPC handler在等待。此时applyListener首先对比：pendingMap中的Op和从applyCh接收的Op是否相同。
若不相同，则表示有新的leader在这个log index处commit了新的entry。这表明本机已经不再是leader。应该遍历所有的pendingChannels键值对，告知所有等待的RPC Handler这个消息（即：向所有等待的RPC Handler发送ErrWrongLeader）。
若相同，则applyListener向对应的RPC Handler发送OK。若对应的RPC是Get，还要同时发送查询到的value值。
上面描述的处理逻辑还不完整。我将在下面的两个部分中加以补全。
Duplicate Detection
如何发现重复的PutAppend请求？
我的实现方式是：每一个client都维护两个值：
1. 一个独特的ID（用递增的int64表示）
2. 一个version number。
每当client要执行一个新的PutAppend请求，该client会将其version number增加1。当client向server发送PutAppend调用时，附上version number。
这样，同一个client的重复请求就可以通过ID+version number加以识别。
在server端，也维护一个以client ID为key，以该client的version number为value的map。每当server成功执行PutAppend请求，都将map中相应ID的version number增加1.
这样，server就可以通过version number来判断client的请求是否已经成功执行。
如果server遇到了已经成功执行过的PutAppend请求，它将直接返回OK。
New Leader Detection
在做这次实验的时候，我的实现在
partitions, one client (3A)
这个测试用例中总是卡住，不能继续向下执行。
在经过各种尝试，都没有效果之后，决定看看别人的博客。
最后终于在https://zhuanlan.zhihu.com/p/130671334 这里找到了问题所在😂
卡住的原因如下：
在我上面描述的实现中，只有当applyListener从applyCh中收到了新的Op，它才能够发现自己已经不再是leader。
若新leader没有commit任何新entry，那么旧leader的KV server将永远不会发现：它已经不再是leader。
因此系统将卡住，无法继续。
为了修复这个问题，我采用了与上面知乎专栏中一样的方法：
修改raft leader，使其在刚刚选举成功时向applyCh发送一条特殊的消息。上层service收到这条消息后，将执行一次rf.Start，在raft log中放置一条特殊的命令。随着这条命令的commit，所有的KV server都将发现有新的server选举成功。
这种实现较为简单，但是其修改了下层raft，我觉得不够完美，但是可以接受。
写在最后
Lab3A比较简单。但是仍然需要精心设计来保证其正常工作。
New leader detection是一个比较难的点，需要额外注意。我主要的时间都花在了这里。
