Raft处理旧领导者

网络分区将领导者和集群其余节点分隔后，其余节点选举出新领导者（由于没有收到心跳），两个领导者在分区的两端分别工作。
问题在于，如果网络分区恢复，旧的领导者重新连接，他并不知道新的领导者已经被选出来，它会尝试作为领导者继续复制和提交日志。如果此时正好有客户端向旧的领导者发送请求，那么旧的领导者会尝试存储该命令，并向其他节点复制日志。
为了阻止这种情况，通过任期来发现过期领导者或候选者，处理逻辑如下：

• 每个RPC请求都包含发送方的任期
• 如果接收放发现发送放的任期陈旧，那么无论哪个过程，该RPC请求都会被拒绝。接收方将已知的最新任期回传给发送方，发送方知道自己的任期已经过期后，转变成跟随者状态并更新其任期。
• 如果接收方发现自己的任期陈旧，那么接收方将自己转变为跟随者，更新自己的任期，然后正常地处理RPC请求。

由于新领导者的选举会更新超过半数服务器的任期，因此旧的领导者即便收到客户端请求也不能提交新的日志，因为它会联系至少一台具有新任期的多数派集群的节点，并发现自己的任期太旧，然后自己转为跟随者继续工作。

当分区后，会出现一种状况，分区的一方没有收到领导者，可能会导致选举Term一直上升，因为无法达到超过半数的选票即3张，因此导致Term一直上涨，等到分区恢复后,由于它的Term最大，导致其他节点不能获得选票，在不断增加Term后，最后才能选出Leader。

解决办法是引入一个Pre-Vote阶段，不仅可以解决解决网络分区时脑裂和任期爆炸增长的问题，还可以解决配置变更干扰领导者的问题。后续进行介绍。