关于图8的StackOverflow，这里有很多问题，在Raft原始论文的5.4.2节中进行了讨论：
图8
论文和任何答案都没有明确的是有问题的条目(2, 3)的确切命运。我的问题有两个：
- S5在第3学期
(2, 3)期间索引2处的条目究竟发生了什么？该数字提到，S5不会成为领导者，因为大多数人会拒绝其请求投票。这是否意味着，在接收到AppendEntries RPC时，S5将按照(e(中的当前前导，用(2, 2)和(3, 4)覆盖其条目(2, 3) - 如果S5被强制覆盖该条目，并且它从未被提交，那么发送
(1, 3)的客户端应该接收什么响应？客户端是否收到未提交条目的确认，就好像它们已经应用到状态机一样
该图提到S5不会成为领导者，因为大多数将拒绝其请求投票
如筏纸中的(e(所示，S5不会成为领先者，因为S5的日志至少与大多数(S1、S2、S3(的日志不同步
这是否意味着在接收到AppendEntries RPC时，S5将根据当前用(2，2(和(3，4(覆盖其条目(2，3((e(中的领导者？
是的，S5的日志将被当前领导者的日志覆盖。引自木筏纸：
如果跟随者的日志与引导者的日志不一致，则AppendEntries一致性检查将在下一个AppendEntrys RPC中失败。拒绝后，引导器递减nextIndex并重试AppendEntries RPC。最终nextIndex将达到领导者和追随者日志匹配的点。当这种情况发生时，AppendEntries将成功，它将删除跟随者日志中任何冲突的条目，并从引导者日志中附加条目(如果有的话(
客户端是否收到未提交条目的确认，如同它们已经应用于状态机了？
否，只有在安全复制了已提交的条目后，客户端才会收到对该条目的确认。请参阅raft paper的报价：
当条目被安全复制(如下所述(时，leader将该条目应用于其状态机并返回结果执行到客户端
还有一种情况是，领导者复制了日志条目，但在响应客户端之前崩溃，或者在通过网络发送响应时丢失，客户端需要重试，导致命令被执行多次。引用自筏纸：
然而，如目前所述，Raft可以多次执行一个命令：例如，如果leader在提交日志条目后但在响应客户端之前崩溃，则客户端将使用新的leader重试该命令，从而使其再次执行。解决方案是客户端为每个命令分配唯一的序列号。然后，状态机跟踪最新的为每个客户端处理的序列号以及相关联的响应。如果它接收到序列号已经执行的命令，它会立即响应，而不重新执行请求