Raft 算法本质：通过一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致 服务节点状态： • 领导者（Leader）：所有请求的处理者，Leader副本接受client的更新请求，本地处理后再同步至多个其他副本 • 跟随者（Follower）：请求的被动更新者，从Leader接受更新请求，当领导者节点故障时，推荐自己进行选举 • 候选人（Candidate）：如果Follower副本在一段时间内没有收到Leader副本的心跳，则判断Leader可能已经故障，此时启动选主过程，此时副本会变成Candidate状态，向其他跟随者节点发送请求投票 RPC 消息，通知投票，若获得大多数节点的投票，则成功竞选为领导者。
服务节点状态变更： • 跟随者 -> 候选人 -> 领导者 • 领导者 -> 跟随者 • 候选人 -> 跟随者
Raft 算法通过任期、领导者心跳消息、随机选举超时时间、先来先服务的投票原则、大多数选票原则等，保证了一个任期只有一位领导，也极大地减少了选举失败的情况。 具体的选举细节如下： • 节点间通讯方式：RPC 通讯，分为请求投票 RPC 和日志复制 RPC。投票 RPC 由候选人发起，通知其他阶段进行投票选举； 日志复制 RPC 由领导者发起，用于日志复制和维持心跳服务。 • 领导者任期：与现实生活中领导者任期不同的是，这里的任期是指任期编号，而非任期时间。跟随者在等待领导者心跳信息超时后，推举自己为候选人时，会增加自己的任期号；如果一个服务器节点，发现自己的任期编号比其他节点小，那么它会更新自己的编号到较大的编号值。 • 在 Raft 算法中约定，如果一个候选人或者领导者，发现自己的任期编号比其他节点小，那么它会立即恢复成跟随者状态 • 如果一个节点接收到一个包含较小的任期编号值的请求，那么它会直接拒绝这个请求 • 选举规则： • 领导者周期性地向所有跟随者发送心跳信息，维持自己的领导者状态 • 跟随者在随机超时时间内没有收到领导者的心跳信息，则发起领导者选举，节点状态变更为候选人，进入选举阶段 • 选举阶段，候选人收到超过半数以上的投票，节点状态变更为领导者，选举结束 • 选举阶段，一个服务节点最多会对一个任期编号投出一张选票，按照“先来先服务”原则进行投票；若任期编号同，则按照“日志完整性”原则进行投票。（日志完整性是服务节点的最后一条日志项对应的任期编号值和索引号。一般情况下，任期编号值更大，索引号更大）。 • 随机超时时间： • 跟随者等待领导者心跳信息超时的时间间隔，是随机的 • 当没有候选人赢得过半票数，选举无效了，这时需要等待一个随机时间间隔，也就是说，等待选举超时的时间间隔，是随机的