如何让 Raft 更稳健，使用 Pre-vote

本文参考文献 《Consensus: Bridging Theory and Practice》

1. Provote 解析原文

该算法解决的是某台机器被隔离后，再次加入时出现的扰动其他机器的问题。

1. 防止服务器重新加入集群时引发的中断

Raft领导者选举算法的一个缺点是，当一台已从集群中隔离出去的服务器重新获得连接时，很可能会导致中断。当服务器被隔离时，它不会收到心跳信号，不久之后它将增加它的任期号并尝试发起选举，尽管它可能没有足够的票数来成为领导者。当服务器某个时候重新获得连接后，它较大的任期号会通过其请求投票或通过其追加条目的响应传播到集群的其他部分。这将迫使集群领导者退位，而必须进行新的选举来选出新的领导者。这样的事件可能很少见，每次只会导致一位领导者退位。

如果需要，可以通过增加额外的阶段来扩展Raft的基本领导者选举算法。

2. 预投票算法

预投票算法的引入是为了解决服务器重新加入集群时中断集群的问题。当服务器被隔离时，它无法增加其任期号，因为它无法从集群的大多数节点那里得到许可。然后，当它重新加入集群时，它仍然无法增加其任期号，因为其他服务器已经定期从领导者那里接收到心跳。一旦服务器接收到来自领导者本身的心跳，它将回到追随者状态（在相同的任期内）。

我们建议在可能从额外的健壮性中受益的部署中扩展预投票。我们还在AvailSim中测试了它在各种领导者选举场景中的表现，发现它并没有显著影响选举性能。

2. 原文