为什么RAFT协议以较低的期限拒绝RequestVote？

如何解决为什么RAFT协议以较低的期限拒绝RequestVote？

在木筏中，每个节点都拒绝任何术语号小于其自身编号的请求。但是，为什么我们需要RequestVote rpc？如果领导者完整性属性成立，那么节点可以为该候选人投票，对吗？那么为什么拒绝请求？我想不出一个例子，在没有这个额外检查的情况下，收到RequestVote时，我们可能会失去一致性，安全性等。

也许有人可以帮助您？

解决方法

在RequestVote RPC中具有较低任期的候选人具有与其他节点不合时宜的日志，因为可以在较高的任期中选举领导者，并且已经将条目复制到大多数服务器。

如果该候选人当选的领导人，筏原因这位领导人的不能够为安全起见，做任何事情的规则。由于期限较低，其RPC将被其他服务器拒绝。

,

我认为有这些原因。

1. 筏中的术语单调增加。先前条款中的所有请求都是基于过时状态提出的请求，只会被拒绝并返回当前条款和领导者信息。
2. 任何选举产生的领导人必须在大选前所有提交的日志，从上一届的候选人是不可能拥有所有提交的日志，因为它不会有任何提交的日志从当前任期。