RAFT论文常见问题总结

1、因为网络问题，先发的appendEntry通知比后发的appendEntry通知晚到server那里怎么办？

答：完全覆盖，没有影响。

考虑到leader更换的问题，没有办法对log顺序进行检查，即使出现第一次结束nextIndex=5,第二次结束nextIndex反退到4的情况也只能接受（中间可能会导致大步回退的情况，按照原始论文只能接受）

2、如果一个leader分发log获得一半以上回复，然后自己commit后没有通知其他follower就崩掉怎么办？

答：Raft里面有描述过，后续leader也一定会包含commit过的log（反推法），因此没有影响

选举时对candidate有限制条件，只有在majority里满足up to date才可以被选举

up to date:优先比较最后一个日志的term，term一样的话就比较长度。term最大log长度最长的server才可能成为新的leader，保证leader commit的日志一定在里面。

性质：如果index一样term一样则command必一样

极大程度降低了比较command内容的成本（命令如果包含多个变量则比较成本很高）

commit之前的记录不会被新的leader所覆写，一个很关键的性质

3、snapshotting相关问题

待完善

4、发生网络分区时leader持续性的问题

通过lease time或者类似lock-set之类的机制进行检验，确保leader每隔一段时间都需要重新确定

5、安全性问题

同一个term只能有一个leader，这是因为一个follower在一个term内只能投一次票，一个candidate需要得到半数以上的票才能成功成为leader。故无法出现一个term内产生两个leader的情况。