为什么或为什么不在Raft实现中将RequestVote RPC用作心跳？

Question

如本文所述，我们将空的AppendEntries RPC用于心跳。那RequestVote RPC又如何呢？当FOLLOWER或CANDIDATE收到RequestVote RPC调用时，是否还应该重置选举超时？为什么或为什么不这样做？
我的一个好处是，当RequestVote RPC调用也被视为心跳时，我们可以潜在地防止出现多个候选条件。由于多个候选人可能会分裂投票并在选举阶段花费更长的时间。通过将其用作心跳，来自一个候选者的RequestVote RPC调用将重置选举计时器，从而使其他活动对等节点也不太可能超时并成为候选者。

Answer 1

好吧，可能天生就没有不安全的地方。但是问题是无法赢得选举的节点仍然可以开始选举。因此，如果无法取胜的节点开始选举并要求所有其他节点投票，则重置其计时器将阻止选举。而且由于无法获胜的候选人首先开始计时，因此很可能也会超时并先开始另一个选举，从而再次阻止集群，再进行一次选举，依此类推。

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