理解raft(2) proVote

问题

FollowerA在选举超时后，没收到心跳, 然后会发起选举，并转为Candidate。每次发起选举时，会把Term加一。但是由于网络隔离，或者说其他的大部分节点还正常连着leader，因此它不会被选成Leader，可是也不会收到Leader的消息，所以会一直不断地发起选举。Term会不断增大。

一段时间之后，这个节点的Term会非常大。在网络恢复之后，这个节点会把它的Term传播到集群的其他节点，导致其他节点更新自己的term，变为Follower。然后触发重新选主，但这个旧的Follower_2节点由于其日志不是最新，并不会成为Leader。整个集群被这个网络隔离过的旧节点扰乱，显然需要避免的。

举例：

有A,B,C,D,E五台机，A是leader，某个时刻A,B出现了分区，但是A,C,D,E以及B,C,D,E都可以互相通信。B在超时没有收到心跳后，把term+1，发起leader选举，如果这段时间C,D,E没有写入更新的日志，由于B的term更大，就会被选为leader，A在后面的RPC中因为自己的term较小也会被降为follower。问题是A成为follower之后又会按照上面B的方式发起选举成为leader，同理B也会再次发起选举，这样周而复始会造成很大的网络开销。

解决方案

上面描述的是非对称网络分区的情况，如果不做特殊处理，会反复出现新的选举，打断正常的 IO，这里一般可以通过 pre-vote 解决，例如，每次发起选举之前，先发起 pre-vote 如果获得大多数 pre-vote 选票，再增大 term 发起选举 vote 投票。为了避免问题描述的情况，其他节点只需要在收到 pre-vote 请求时，判断一下 leader 是否还在，一般实现上，判断最近和 leader 是否正常通信，如果有，那么说明 leader 正常在线，直接拒绝 pre-vote 即可。

或者用租约，follower只要在租期(属于某个leader)内，如果不是强制转移leader，那么就忽略term大的votemsg。