algorithm - 为什么或为什么不使用 RequestVote RPC 作为 Raft 实现中的心跳？

Question

正如论文中介绍的，我们使用空的 AppendEntries RPC 进行心跳。那么 RequestVote RPC 呢？当 FOLLOWER 或 CANDIDATE 收到 RequestVote RPC 调用时，是否也要重置选举超时？为什么或为什么不这样做？
我认为的一个好处是，当 RequestVote RPC 调用也被视为心跳时，我们可以潜在地防止多个候选条件。由于多个候选人可能会分裂选票并在选举阶段花费更长的时间。通过将其用作心跳，来自一个候选人的 RequestVote RPC 调用将重置选举计时器，以便其他实时对等方不太可能超时并成为候选人。

Answer 1

好吧，它可能没有任何本质上不安全的地方。But the problem is nodes that can't win an election can still start one. 因此，如果一个无法获胜的节点开始选举并向所有其他节点请求投票，则重置其计时器将阻止选举。而且由于无法获胜的候选人首先启动了它的计时器，它很可能也会超时并首先开始另一次选举，从而再次阻塞集群，然后再进行一次选举，依此类推。

当然，解决此问题的方法可能是仅在投票时重置选举超时。这可能是安全的。毕竟，选举超时无论如何都是随机的。但问题是它是否有效。它不会阻止拆分投票，因为它不会阻止多个节点同时请求投票，并且在拆分投票期间它只会使选举花费更长的时间。由于这个原因，我怀疑预投票协议效率更高，并且可能会避免分裂投票以及可以避免的投票。