一、主要概念:(可先大致了解,后面图文解析更方便理解)
在开始下一部分内容之前,可以先玩下raft演示,不过后面第三章的图文解析将用更详细的演示图。
二、raft算法规则设计
- 如果获得大部分节点的赞成票,则成为leader;
- 如果接收到新leader的appendEntries RPC,则回退到follower;
- 如果该任期没有结果,重新等待所有节点中的其中一个(包括自己)成为candidate,重新开始选举过程;
- 如果存在一个满足N > commitIndex和大部分节点的matchIndex >= N并且log[N].term == currentTerm的 N,则将commitIndex赋值为 N。这条规则隐藏两层意思,一是存在多条日志已经被多数follower节点复制,也就是先更新matchindex,当多数节点的matchIndex都更新后才更新commitIndex。二是leader只能提交当前任期的日志,如果有往期的日志有多数复制了,不能由当前任期的leader提交,二是在当期leader提交当期日志时,间接提交。这也表明有可能有些日志没有执行到状态机,那么就需要检测lastApplied是否小于commitIndex,从而执行往期的指令。
三、选举与日志复制图文解析
在开始之前,先介绍一个模拟raft的工具,如下图:
场景模拟演示与解析
这部分内容,会根据不同场景解释第二章中的规则;
1、选举
场景1:所有节点都正常
场景2:leader节点宕机,剩下4个节点参与选举
四节点选举时,存在两种情况(1、一个候选者获取多数选票,2、两个候选者各获得一半选票),不过这里合并一起讲。
场景3:宕机节点重启,并很快到达选举超时计时
这种情况实际包含了s4正常重新加入集群的情况,只不过前面多了一点插曲
场景4:某个follower节点在某段时间因为网络问题无法收到leader的心跳请求,在这段时间内成为candidate,在发送vote请求时,网络又恢复正常
以上均是不含日志情况下的选举(日志条数一样的情况类似),下面将分析日志条数不一样的场景
首先先模拟场景(这个模拟也是模拟脑裂的场景,只不过这个模拟工具无法实现网络阻隔,但是这难不倒我们,我们可以分步来)
当candidate和follower日志不同的时候,选举情况看似复杂,其实是归结起来就两句话:日志里最后一个log entry的term更大的日志更加新,如果这个term相等,那么最后个log entry 的index更大的日志更新。
2、日志复制
场景1、leader固定一个,新增日志顺序复制
场景2、在leader复制完日志收到大多数确认之后,发生网络问题,leader切到其他节点。
那么往期的多数复制的日志什么时候提交呢?请看下图:
这里就演示了,即便大多数复制的内容也可能被覆盖。如果在步骤(9)中s1在完成多数节点复制后提交了往期的日志并执行到状态机,但是还没将提交状态同步到其他节点,或者已经同步了状态。此时S5发起的vote请求依然能成为leader,顺利完成(9)之后的流程,这样就覆盖了已提交的log,与状态机的状态不一致了。
那为什么当期提交就没问题呢?
当期的leader能保证提交当期的日志时最新的,往期的日志leader不能保证是最新的(比如s5的第四个log entry才是整个集群最新的日志记录)。
那么只有在多数复制后,又有新的当期日志(肯定是所有节点中最新的)提交,才能顺带往往期的一起提交:
这个图就不再解析了,上面的流程都讲到过相关的内容
很明确的一点:已经提交应用到状态机的日志,不能被覆盖修改,这是数据一致性安全的要求。
3、leader的完整性(Leader Completeness Properties)验证
论文中对leader的完整性(Leader Completeness Properties)用了一个很啰嗦的反证。其实就是只要是leader能确认提交的日志肯定是多数复制了,且当前任期号的日志肯定是最新的日志,那么下一任期选举,一定会有包含该条最新日志的节点参与选举才能有节点得到多数选票,且一定是包含最新日志的节点得到多数选票。
后面的成员配置边和日志压缩等就先不玩了。。。
参考:
http://thesecretlivesofdata.com/raft/
https://raft.github.io/raftscope/index.html
https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md#51-raft-%E5%9F%BA%E7%A1%80
https://zhuanlan.zhihu.com/p/32052223
https://www.cnblogs.com/xybaby/p/10124083.html
https://blog.csdn.net/ppvqq/article/details/78572898