在RAFT中，是否可以在日志条目上达成多数共识，但条目未提交？

Question

在官方raft webpage

中考虑此模拟

尽管term 2 index 1，S2 (leader)和S3同意日志，为什么S4仍未提交？我运行这几分钟以确保所有通信都已发生。

奇怪的是，如果我再添加一个日志条目term 6 index 2，则会提交term 2 index 1。

有谁知道阻止term 2 index 1被提交的规则是什么？

Answer 1

你的领导者在第6学期，但没有一个日志条目来自第6学期;这在Raft中引用了一个特殊规则。领导者不会自动提交前一个词条，因为在某些情况下这样做是不安全的。第5.3和5.4节详细讨论了这一点（另见图8）。

从第5.4.2节开始：

  

消除类似图8中的问题，Raft   永远不会通过计数提交以前术语的日志条目   副本。仅记录领导者当前的条目   术语是通过计算复制品来实现的;一次进入   从现在这个词一直以这种方式承诺，   然后所有先前的条目都间接提交，因为   日志匹配属性。有一些情况   领导者可以安全地得出一个较旧的日志条目   已提交（例如，如果该条目存储在每个条目上）   服务器），但Raft采取更保守的方法   为简单起见

您的示例已完美设置，以说明这是不安全的原因。假设S2 确实提交了，然后我们通过将两个东西提交到同一个插槽来打破它。

1. S2提交插槽1（本地）。
2. S2发送AppendEntries(commitIndex=1, [])。
3. S3接收并应用AppendEntries(commitIndex=1)。
   • 2现已在两台主机上提交。
   • 其他主机无法收到该消息。
4. S1当选为领导人
   • S1比任何其他日志（§5.4.1）都“更新”，并且很容易赢得选举。
5. S1发送AppendEntries([4])。
   • 领导者所做的第一件事就是让所有其他日志看起来都是自己的。
6. S4接收并申请AppendEntries([4])。
   • 这将在插槽1处覆盖其值2。
7. S5接收并应用AppendEntries([4])。
8. S1在本地提交4
   • 我们已经破解了!! 两个承诺的值
9. S2，S3接收并申请AppendEntries([4])。
   • 我们已经双重打破它，我们丢失了已提交的数据!!
   • 一位优秀的工程师会在这里提出一个断言来抓住这个覆盖。

发生什么事了？实质上，我们为同一个时段选出了两个不同的领导者。 （当S1更新时，S2当选为领导者。）

为什么领导者在不等待后续请求的情况下提交自己的条款是否安全？因为不可能进入上述情况。让我们考虑两个节点（S2，S1）分别认为它们在第2和第3项中同时是领导者的情况。如果S2已准备好将2提交到插槽1，那么大多数具有相同的值。这意味着没有多数人投票支持另一个在第1个插槽中有更高期限的内容。这意味着S1，在第3阶段当选为领导者，必须在第1个插槽中有2。

（顺便说一下，我花了一分钟时间弄清楚你是如何进入这种情况的。）

另外，Raft作为“Paxos更易理解的版本”推向市场。我不同意：它似乎有这么多（如果不是更多）角落案例。但是，Raft的作者非常善于让工程师轻松地正确实现某些实用的东西。这与作者如何撰写筏纸有关。