筏算法的巨大缺陷

Question

所以 raft 论文和论文说这是处理附加条目的方法：

接收器实现：

1. 如果术语 < currentTerm (§5.1)
则回复错误
2. 如果日志在 prevLogIndex 中不包含术语与 prevLogTerm 匹配的条目，则回复 false (§5.3)
3. 如果现有条目与新条目冲突（相同索引但术语不同），删除现有条目及其后的所有条目 (§5.3)
4. 追加日志中没有的任何新条目
5. If If leaderCommit > commitIndex, set commitIndex = min(leaderCommit, index of last new entry)

领导：

• 选举时：发送初始的空 AppendEntries RPC（心跳）到 每个服务器；在空闲期间重复以防止选举超时 (§5.2)

• 如果从客户端收到命令：将条目附加到本地日志，响应 进入状态机后（§5.3）

• 如果关注者的最后一个日志索引 ≥ nextIndex：发送 AppendEntries 日志条目从 nextIndex 开始的 RPC

• 如果成功：更新关注者的 nextIndex 和 matchIndex (§5.3)

• 如果AppendEntries因为日志不一致而失败：减量 nextIndex 并重试（§5.3）

• 如果存在 N > commitIndex，则大多数 matchIndex[i] ≥ N, and log[N].term == currentTerm: set commitIndex = N （§5.3，§5.4）。

服务器规则 图 2：Raft 共识算法的简要总结（不包括成员变更和 log co

但是，这在您一次发送超过 1 个条目的情况下根本行不通。如果我发送 3 个条目，一次成功只会增加 1，大声笑。我如何理解这一点？我们如何能够确认所有条目都是从 nextIndex[serverId] -> 发送到日志末尾的？