➢ 某一时刻，其中的一个 follower 由于没有收到 leader 的 heartbeat 率先发生 election timeout 进而发起选举。
➢ 只要集群中超过半数的节点接受投票，candidate 节点将成为即切换 leader 状态。
➢ 成为 leader 节点之后，leader 将定时向 follower 节点同步日志并发送 heartbeat。
如果leader节点出现了故障，那怎么办？
下面将说明当集群中的 leader 节点不可用时，raft 集群是如何应对的。
➢ 一般情况下，leader 节点定时发送 heartbeat 到 follower 节点。
➢ 由于某些异常导致 leader 不再发送 heartbeat ，或 follower 无法收到 heartbeat 。
➢ 当某一 follower 发生election timeout 时，其状态变更为 candidate，并向其他 follower 发起投票。
➢ 当超过半数的 follower 接受投票后，这一节点将成为新的 leader，leader 的任期号term加1并开始向 follower 同步日志。
➢ 当一段时间之后，如果之前的 leader 再次加入集群，则两个 leader 比较彼此的任期号，任期号低的leader将切换自己的状态为follower。
➢ 较早前 leader 中不一致的日志将被清除，并与现有 leader 中的日志保持一致。
还有第三种可能性就是candidate既没选举成功也没选举失败：如果多个follower同时成为candidate去拉选票，导致选票分散，任何candidate都没拿到大多数选票，这种情况下Raft使用超时机制election timeout来解决。所以同时出现多个candidate的可能性不大，即使机缘巧合同时出现了多个candidate导致选票分散，那么它们就等待自己的election timeout超时，重新开始一次新选举，实验也证明这个机制在选举过程中收敛速度很快。
3.2 Log Relocation在 raft 集群中，所有日志都必须首先提交至 leader 节点。leader 在每个 heartbeat 向 follower 发送AppendEntries RPC同步日志，follower如果发现没问题，复制成功后会给leader一个表示成功的ACK，leader收到超过半数的ACK后应用该日志，返回客户端执行结果。若 follower 节点宕机、运行缓慢或者丢包，则 leader 节点会不断重试AppendEntries RPC，直到所有 follower 节点最终都复制所有日志条目。
上述的具体过程如下：
➢ 首先有一条 uncommitted 的日志条目提交至 leader 节点。