Raft leader 选举
通信：两种类型的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。相同的机制也用来处理平票问题。