Raft

leader

follower

candidate

投票请求，投票阶段由候选者发送

主从同步请求，是由leader发送的日志数据，日志数据为空表示心跳

快照请求

相当于一个逻辑时钟，每个节点维护自己的任期，是单调递增的，当一个节点收到的请求的任期大于自身，则更新自己的任期，如果小于自身，则拒绝这个请求

一个任期包括选举和正常处理客户端请求2个阶段，每个任期最多产生一个leader（大多数选票，节点在一个任期按照先到先得只给一个候选者投票）

如果收到的请求的任期大于自己，更新自己的任期；当候选者或leader收到的任期大于自己，则转变为follower

请求的任期大于等于自己，如果大于，更新自己的任期

在自己的任期内没有投过选票，或者投过相同的选票

最新日志的任期和索引大于等于自己，以确保选出来的leader具有所有已提交的日志

必须要大于等于集群节点间发起请求到响应的平均时间

小于等于节点宕机的平均时间间隔

用于日志一致性检查，索引和任期都相同表示这2条日志以及它们之前的日志都相同

用于网络分区恢复时的数据一致性检查，分区的不同集群的日志任期不同，分区故障恢复后，相同日志索引，取任期大的作为最终日志

写入状态机，持久化，最终写入所有节点的状态机（所有节点最终都需要提交日志）

提交索引由leader通过同步请求发送给follower，follower收到后写入自己的状态机

为了解决已提交的旧的日志被覆盖，raft规定不能直接提交当前任期之前的日志，只能提交当前任期的日志，而之前的日志被间接提交

同步的请求中包含了同步数据前一条的索引(nextIndex)和任期，follower收到后，检查索引和任期在自身日志中存在，才能接收该请求，从nextIndex+1开始追加或覆盖

一致性检查不通过时，leader减少同步数据的索引(nextIndex)，重发请求，直到匹配为止。这时follower冲突部分的日志会被覆盖

leader维护了每个节点的nextIndex，初始值为leader最大日志索引+1，然后通过一致性检查来逐步更新为匹配的最大日志索引

并存配置的节点需要新旧2个集群过半同意，所以并存配置的节点和旧的配置的节点只会产生唯一一个leader

当并存配置提交时，说明过半节点已拥有并存配置，这时旧节点不可能选为leader，因为并存配置节点日志更新，得不到过半投票。这时可以安全地切换到新配置

扩容时，如果新加入的节点比较多，使得过半机制需要包含这些节点，那么由于它们需要同步旧数据，将导致客户端发送的新数据迟迟得不到响应。
解决方法：新加入的节点只同步数据，不参与过半机制，直到日志数据跟上leader进度后，leader才开始写入并存配置，进行配置变更。

缩容时，如果leader不在新集群中，那么日志复制时的过半统计不统计自己，当写入新配置时，转为follower并下线

缩容时，移除的节点会干扰新集群

大多数情况下，节点独立生成各自快照，只有当leader没有follower需要的日志（已生成快照并且删除了），才会将快照发送给follower，一般发生在慢follower和新加入的节点

快照文件是按序分块传输的，当前块在快照文件的起始偏移量，0表示创建一个新的快照文件

客户端读如果直接从Leader读，可能因为网络分区（2个leader）的原因从过期leader读到过期数据，所以读也需要额外的操作：
1、任期开始时leader是不知道提交索引的位置的，因此通过提交一个空的日志来确定提交索引，其实就是在任期开始时，leader会提交所有的日志
2、在响应读请求之前，leader需要先发送一次心跳来确认是否分区故障而被废弃