理解Raft算法

网上已经有很多关于raft的文章，我看下来的建议阅读顺序是：

1. 知乎 《Raft算法详解》 比较通俗易懂的描述了raft
2. github 《寻找一种易于理解的一致性算法（扩展版）》 该文是raft文献的一个翻译，翻译的还是比较流畅易懂的
3. 简书 《Raft （3）— 安全性》 本文主要是对安全性的更加易懂的解释，主要是我在阅读安全性章节时，出于对“安全性”的不理解又做了一些探讨。

下面是以Q&A的方式自己的总结，对于应试帮助比较大：

Q1: raft算法的目的
A1: 解决分布式架构下的副本一致性问题。

Q2: raft的角色和状态变化
A2: leader, candidate, follower. 任一时刻最多有一个leader，这也是和Paxos的一个区别

Q3: 选举的过程
A3: 开始时角色初始化为follower，来自leader的心跳超时（这时因为没有leader） follower转变为candidate 增加term发起选举。选举请求带了term和index，是否被选举取决于term大于请求接受方，如果相等再比较index大。
选出leader后，leader通过心跳与其他node保持关系。

Q4: 安全性，为了解决什么问题？怎么解决的？
A4: 在开篇条的安全性文章中都有下面一张图，开篇的简书里的内容我直接拿过来说明

在term1过后，进入term2，S1经过投票选举为了leader，复制client传来的任期2的entries。
此时{index:2,term:2}只复制到了S2，S1就崩掉了，此时S5上位（S3、S4、S5三票），此时term为3，收到了来自client的请求。
过了一会处于term3的leader（S5）崩掉了，S1在恢复后，重新成为leader(term4)，收到client的新请求（index：3，term：4），复制过去{term：2，index：2}的entry到S3，此时按照过去的committed标准（只要存在大多数副本的日志里），index为2的这条entry被认为可提交，当要提交时，S1崩溃了。
S5当选leader，进行{term:3,index:2}的复制，此时进行日志校验，发现只有index：1一致，于是从此之后的{term:2,index:2}被覆盖为{term:3,index:2}
那么之前{term:2,index:2}被认为可持久化的log entry被覆盖了，不安全！

这里是Q4中提到的要解决的问题是什么： 如果没有安全性原则，{term:2,index:2}达到了历史任期中被复制到“大多数”机器的情况是需要被提交的，然而提交前leader挂了，leader再回来的时候已经是下一个term了，如果这个这时leader还要管理历史term下要提交的情况，此时又挂了，那么{term:2,index:2}会被S5的动作覆盖，不符合要求。
所以解决方案是：1. 定义最新的log，是term + index 对比
2. leader只判断当前term的log复制是否达到commit状态，一旦commit，那么之前的copy也会被commit。 但是如果没有达到commit状态又宕机 被抢主，本身历史log就不是约定的必须要commit的，所以就不用处理。

Q5: 如果S5不是宕机，而是因为网络问题与其他node在不同的网络分区，那么S5会不断地自己进行选举增加自己的term，然后在term很高的时候恢复了与原集群的网络，那么这时候他的term最高，岂不是他才会被选主（但是他的index又不是最新的）
A5: S5网络分区前是{term:10, index5}后，他的term因为election不停的增加到20，但是在网络恢复后，他发出去的vote请求里带的term应该不是20, 而是具有最高index（5）所对应的term，也就是10. 所以他的vote请求会大概率被拒绝