6.824 lab 2B2C

环境准备

环境准备

lab 1

lab1

lab 2A

lab 2A

lab 2B

把论文的第五节看完就能写了，细节都写在figure2上了。

一些理解

1、我设计的Entry包含Term、Index、Command三个属性。
2、matchIndex和nextIndex在设计的时候要考虑到，这两个值可以区分出，对应的follow是已经完成了匹配还是在匹配的过程中。我在log中都加了一个term和index为0的Entry，这样可以不用对空log做额外的处理。
3、投票的限制。先考虑term，如果term都不满足就直接返回，如果term满足，再去比较index。

4、在完成日志复制之后，要丢后面所有的entry。否则，在上图的情况中就会出现问题。⚪内的数字是server的编号，旁边是对应存储的日志，格子内的数字代表对应的term。现在2号是leader，发现1号前面10个不匹配，在完成匹配之后，如果没有将多处理的90个entry丢弃，又正好赶上2号断开链接（还没有对3号做日志同步），那根据投票限制，1号最后一个entry的term是1，3号最后一个entry的term是2，1号会投票给3号，3号当选。但是正确的情况应该是1号当选。
5、提交entry。我的思路是再开一个线程，循环的去提交appliedIndex到commitIndex之间的entry。对于leader做一个特殊的判断，去更新leader的commitIndex。先去寻找最近的一个未提交，且term与当前term相等的entry，然后再统计matchIndex大于这个entry的index的个数，个数超过一半就将commitIndex更新。

lab 2C

2C的内容非常少，按照给的例子实现persist()和readPersist(data []byte)就行。
调用persist()的位置有几个地方，更新log、term、votedFor之后。
对于优化日志的匹配，我是每次向前走一个term。
这个部分主要是在测试的时候，会包含2B没有测试到的地方，2B可能会有一些没测试到的bug在这里被测出来。
建议把三个部分都测试1000次

总结

lab 2还是比lab 1难了很多的，但是在做完之后觉得难度还行，主要是根据论文实现，论文里讲得也比较清楚。只要在2A里把调用的架子搭好了，剩下两个部分只是往架子里面填东西。