通信：两种类型的 RPC
RequestVote RPCs candidates during elections.
AppendEntries RPC leaders to replicate log entries and to provide a form of heartbeat.
leader 选举
Raft 使用一个 heartbeat 机制触发 leader 选举。当 servers 启动，首先成为 followers。只要 server 收到来自 leader 或 candidate 的有效 RPCs 消息，就一直保持 follower 的状态。Leaders 定期给所有的 followers 发送 heartbeat，以维护它的统治。如果一个 follower 超过一定时间未通信，则叫作 election timeout，然后就假设现在没有有效的 leader，然后开始选举流程选出新的 leader。在选举之前，follower 自增它当前的 term 号，转化为 candidate 状态。然后投票给自己，并并行地给剩下的每一个 server 发送 RequestVote RPCs。Candidate 保持 candidate 的状态直到下面的一种情况发生：(a) 此 candidate 赢得选举；(b) 另一个 server 已被选为 leader；(c) 一段时间过去后仍没有 server 胜出。下面的章节将分开讨论这些情况 (a) 在同一个 term 中，如果 candidate 获得大多数 servers 的选票，此 candidate 赢得此次选举。在给定的 term 中，每一个 server 最低投票给一个 candidate，遵守先来先得的原则。大多数的规则保证最多一个 candidate 在特定的 term 中赢得选举。一旦一个 candidate 赢得选举，它就成为 leader。然后就开始发送 heartbeat 信息到其他所有的 servers 来建立它的权威并阻止新的选举。(b) 在等待投票的过程中，candidate 可能会收到来自其他自称是 leader 的 server 的 AppendEntries RPC。如果 leader 的 term 号至少与 candidate 的当前 term 号一样大，则这个 candidate 就认为这个 leader 是合理的，然后退回到 follower 的状态。如果 term 号小于 candidate 的，则拒绝 RPC 并继续保持 candidate 状态。(c) 第三种结果是 candidate 既没有赢也没输：如果许多 followers 同时成为 candidates，可能会发生平票。这种情况下，每一个 candidate 将 timeout，通过递增 term 开始一个新的选举，产生新一轮的 RequestVote RPCs。然而，没有额外的措施，平票会无限重复下去。Raft 使用随机生成的选举 timeouts 来保证平票发生的机会很少，并很快解决。为了第一时间阻止平票，选举 timeouts 在一个固定区间内随机产生（e.g., 150-300ms)，从而保证在大多数情况下，最多有一个 server 将 time out; 它赢得选举并在其他 servers time out 之前发送 heartbeats。相同的机制也用来处理平票问题。