本期视频已更新，欢迎一键三连！ 要是 raft 算法这么讲，我就懂了_哔哩哔哩_bilibili
算法流程
选举leader
我们集群中有5个节点，每一个节点有一个超时时间，最开始集群中大家都在等待超时，选举的流程如下：
- 超时后节点进入 candidate 状态，term加1.然后向其他节点发布投票请求，图中是 S2 优先进入 candidate 状态。
- 当其他节点收到投票请求后，会判断自己的term和被投票者(S2)的term大小
- 如果当前节点的term 小于被投票者(S2)则会投入赞成票，同时自己的term修改为被投票节点的term，否则是反对票
- 如果被投票者(S2) 收到的赞成票超过半数，则当前节点(S2)会晋升为leader节点
- leader节点广播出信息 ，宣布自己成为 leader 节点
- leader和其他节点发送心跳检测响应
- 如果超时没有收到心跳，节点会再次进入 candidate
数据同步
- 当我们写入数据的时候，首先写入 leader节点
- leader 节点把数据 (proposal) 进行广播出去
- 其他节点收到数据后，返回对应的ack消息
- 当leader 收到ack消息超过半数，自己提交事务，然后通通知其他节点提交数据
- 各个节点数据提交完成，数据同步完成
其他情况
竞争选举
如果同时出现了两个节点同时超时的时候会出现什么情况？
- 两个节点 S1,S2同时发出投票请求
- 其他节点以S5 为例，当先收到 S1 的投票请求时候，由于term <2 所以S5投了赞成票，同时把自己的term改成2 。当再次收到 S2 的请求的发现term=2 所以投了反对票
- S1 和 S2 由于term 一样，所以相互投了反对票。
- 其他节点也是一样的，谁的票先到，就投递赞成票。
- 对于当前情况 S1 节点优先获得半数以上投票，然后作为leader 对外广播。
崩溃恢复
崩溃恢复是对一个分布式算法来说是非常重要的，对于leader节点来说，宕机主要有两种情况：
- 宕机时候无数据待同步到其他节点，当前数据已经同步完成。这个时候只需要做正常的选举就可以了
- 宕机时候有待提交的数据，如果这个时候 leader 已经被写入了数据，那其他节点的数据应该有一下几种情况
-
- 没有同步到其他节点，在下次选举出leader的时候，由于leader中没有当前数据，所以当前数据会丢失，如图S2的【2】这个数据会丢失
-
- 已经同步其他节点，但是还未提交。如果这个时候leader节点崩溃，则新的leader中有最新的数据，但是新的leader不会立即提交当前数据，而是等待下一次数据到达时候一起提交。
-
- 自己已经提交，然后通知其他其他节点提交的时候宕机。这种情况和第二种情况一样。
其他情况
新的 candidate 数据和集群不一致情况下，选举结果会是如何？
、、
