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。相同的机制也用来处理平票问题。