分布式协议之raft的一些问题总结

情况1：

问题：假设现在有S1,S2,S3,S4,S5，五个节点，领导者S5接受了一个add请求，现在自己日志add了，然后发送信息让其他节点S1,S2,S3,S4,也add到日志了。这个时候领导者S5宕机了，也就是说接收不到其他节点的成功返回信息了，不能进行commit操作，怎能办？这个add操作还有效吗？

解答：add操作有效。
题目情况时，S5宕机，其他节点重现选举，选出新的任期领导者，新的领导者收到新的add信息，准备提交时，同时也将原S5任期添加的信息一块提交了。
如下：
S5宕机，此时，各个节点已经更新任期2日志条目，此时没有提交（commit）。

S5宕机后，其他节点重新选举。新领导者S2，任期3。节点3更新提交条目的时候，原任期2的日志条目也被提交了。

S5重启，S5角色是跟随者，任期为3，原来任期2,现在任期3的日志会被同步。和领导者保持一致。

情况2：

问题：假设现在有S1,S2,S3,S4,S5，五个节点，领导者S5接受了一个add请求，现在自己日志add了，然后发送信息让节点S1,S2,S3,进行更新日志，还没对 S4发送，这个时候领导者S5挂了怎能办？如果这时候还是S先到了过期时间，S向S,S,S,发送了投票请求会发生什么？

解答：S5挂掉，S4超时 时，S4请求投票，但S1,S2,S3拒绝投票。（原因：S1,2,3,检测S4完整度没自己高，比较index）。继续进行下一次选举。

S5挂掉，S4超时 时：

S4被拒绝投票后，重新选举结果，S3当选领导者。如下图：

S3再收到客户端请求，会更新最新日志，任期2的日志也同时会被提交。

情况3：

问题：假设现在有S1,S2,S3,S4,S5，五个节点，领导者S2接受了一个请求，让S4更新了，还没让S1,S3,S5更新就宕机了，这个时候还是S3先TIMEOUT了，会发生什么？这个和情况2有什么不同？

解答：S2宕机，S4更新，S3timeout时，S3发起投票，S4会因为index比S3大拒绝，但S1，S2，多数会接受，同意。S3当选领导者。S3添加日志，会覆盖S4日志（按照领导者的index来维护日志Index）。
情况2，S1,S2,S3,是已经存在有日志更新了，占据了绝大多数，另一个不会被选上。选上的是S1,S2,S3,其中之一，包含已经存在的日志，不会被覆盖。

S2宕机，S4更新：

S3timeout时，S3发起投票：
S3日志覆盖S2，S4日志。

注：本文图片来源，是raft可视化演示截图，自己调节每种情况参数。
链接: https://raft.github.io/.