终于做完了mit6.824的lab2A，估计总用时大概10小时左右。代码在：
https://gitee.com/mphyatyh/mit6.824
我的用时远远超出了课程给出的中等难度的实验（Moderate）用时应该在6小时以内的标准。总结原因有以下一些：
1、 没有认真看下面这个链接中给出课程实验框架的交互图，开始的时候走了弯路，我尝试把一个raft实例的所有事件处理都放到一个goroutine里面，后来发现要把接收到的RPC request和reply放到一个goroutine里面很麻烦，要自己构造队列，要给这些事件重新打上标签，但是这样做似乎并没有什么好处。
https://pdos.csail.mit.edu/6.824/notes/raft_diagram.pdf
2、 虽然读了多遍论文，但对raft协议本身还有些地方理解不透。例如：在candidate状态收到更新term的RV，是不是应该立即把自己的状态变为follower？按照下面这个图上说法是应该的，因为这算是从Candidate到Follower两种触发条件之一。
但是，文中5.2节又说：
A candidate continues in this state until one of three things happens: (a) it wins the election, (b) another server establishes itself as leader, or (c) a period of time goes by with no winner.
上面这三种情况应该不包括：“discovers new term”，自己琢磨感觉这种情况应该是上面的第三种情况：“(c) a period of time goes by with no winner”，因为一旦收到了新term的RV，就说明别的节点已经超时了，尽管这个节点自己没有超时，那么应该算是“一段时间过去了但是没选出Leader”。实验可以加深对论文的理解，这也许就是动手做这个实验的意义所在了。
3、 部分代码是利用出差路上机场等飞机、飞行途中等时间完成的，这些时间段内效率不高，环境不好，干扰因素比较多，很难全身心沉静下来写代码。
从实现角度看，Raft协议本身的确比Paxos（Multi Paxos）更容易理解。但是文章的描述对代码实现并不友好，如果能够用更准确的语言来描述协议，那么写代码就会更容易。我曾经实现过LLC协议，协议文本里面有一张表来描述协议状态机转换，类似下面这样，这种表格对写代码的指导作用更好。
另外，文章中对协议机制的背后动机的描述也不多，比如：为什么协议中要设计一个Term？文中只有一句话：Terms act as a logical clock[14] in Raft, and the allow servers to detect obsolete information such as state leaders. 我为了理解这句话，又去找了关于logical clock材料。我认为类似这些地方可以多花一点笔墨描述。
题图：筏子
