Raft follower 应该在什么时候记录 RPC？

如何解决Raft follower 应该在什么时候记录 RPC？

我正在从 paper's extended version 学习 Raft。在论文的第 5.2 节（领导人选举）中，它说：

如果跟随者在称为选举超时的一段时间内未收到任何通信，则它假定没有可行的领导者并开始选举以选择新的领导者。

同时，论文称在某些情况下可以拒绝 RPC，例如当它包含较小的术语编号时。

我的问题是：follower 何时应该将 RPC 识别为有效的“通信”并进行记录以防止其超时？

编辑：

我目前的实现如下：

RequestVote 仅在服务器授予投票权时重置超时
AppendEntries 如果其期限不小于服务器的期限，则重置超时

这在大多数情况下都可以正常工作，但有时会导致选举时间过长。考虑一个具有 2 个服务器的 Raft 集群，两个服务器都是跟随者。服务器 #1 有更新的日志，但服务器 #2 有更大的期限。

在这种情况下，服务器 #1 必须连续开始 2 次选举才能成为领导者，这（直觉上）以

解决方法

作为 Follower 的 Raft 节点响应两种类型的请求：

附加来自领导者的条目
请求候选人投票

如果 Follower 收到来自当前 Leader 的 AppendEntries，它应该做所有的检查（即来自请求的 term，日志匹配），如果所有的检查都得到满足，Follower 应该从请求中附加收到的条目。 Follower 还应该在从当前 Leader 接收 AppendEntries 时重置选举超时，因为 AppendEntries 还充当心跳（Leaders 还会定期发送没有日志的 AppendEntries 请求，以防止 Follower 超时并开始新的选举）。>

如果 Follower 收到 RequestVote RPC，并且如果 Follower 决定将其投票授予该 Candidate，则 Follower 也会重置其选举超时。