问题描述
在StackOverflow上，图8周围存在许多问题，在original Raft paper的5.4.2节中进行了讨论：
该论文尚未阐明，也没有一个答案是那个有问题的条目(2,3)的确切命运。我的问题有两个：
- 由S5制定的第3项
(2,3)在索引2处的输入究竟发生了什么？该图提到S5不会成为领导者，因为大多数人会拒绝它的RequestVotes。这是否意味着在接收到AppendEntries RPC之后，S5随后将按照（e）中的当前领导者用(2,3)和(2,2)覆盖其条目(3,4)吗？ - 如果S5被迫覆盖此条目，并且从未提交，则发送
(1,3)的客户端应该收到什么响应？客户端是否收到未提交条目的确认，就像已经将其应用于状态机一样？
解决方法
该图提到S5不会成为领导者，因为多数 将拒绝其RequestVotes
如（e）的牛皮纸中所示，S5不会成为领导者，因为S5的日志至少不与多数日志（S1，S2，S3）保持最新
这是否意味着在收到AppendEntries RPC后，S5将随后 根据当前用（2，2）和（3，4）覆盖其条目（2，3） （e）的领导者？
是的，S5的日志将被当前领导者的日志覆盖。引自牛皮纸：
如果关注者的日志与领导者的日志不一致，则下一个AppendEntries RPC中的AppendEntries一致性检查将失败。拒绝后，领导者递减nextIndex并重试AppendEntries RPC。最终nextIndex将到达领导者和关注者日志匹配的地步。发生这种情况时，AppendEntries将成功执行，这将删除关注者日志中的所有冲突条目，并从领导者的日志中添加条目（如果有）。
客户端是否收到未提交条目的确认，就像 他们已经被应用到状态机上了吗？
否，只有安全地复制了条目后，客户端才会收到已提交条目的确认。请参阅牛皮纸报价：
安全地复制了该条目（如下所述）后，领导者将该条目应用于其状态机并返回该结果的结果 对客户执行。
在某些情况下，领导者已经复制了日志条目，但是在响应客户端之前崩溃了，或者在通过网络发送时响应丢失了，客户端需要重试导致命令多次执行。从木筏上喊出来：
但是，到目前为止，Raft可以多次执行命令：例如，如果领导者在提交日志条目之后但在响应客户端之前崩溃，则客户端将使用新的领导者，导致第二次执行。解决方案是让客户端为每个命令分配唯一的序列号。然后，状态机跟踪最新的 为每个客户端处理的序列号以及相关的响应。如果收到已执行序列号的命令，它将立即响应而无需重新执行请求