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

Question

在官方筏网页上考虑这种模拟

为什么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]).
   • 这将2在插槽1处覆盖其值.
7. S5接收并申请AppendEntries([4]).
8. S1在4当地 提交
   • 我们打破了!! 两个承诺的价值观
9. S2,S3接收并申请AppendEntries([4]).
   • 我们已经倍加打破它,我们丢失了承诺的数据!!
   • 一个优秀的工程师会在这里设置一个断言以捕获这个覆盖.

发生了什么？实质上,我们为同一个时段选出了两个不同的领导者.(当S1更新时,S2当选为领导者.)

那么为什么领导者在没有等待后续请求的情况下提交自己的条款是否安全呢？因为不可能进入上述情况.让我们考虑两个节点(S2,S1)分别认为它们在第2和第3项中同时是领导者的情况.如果S2准备好2进入插槽1,则多数具有相同的值.这意味着没有多数人投票支持在插槽1中有更高期限的任何其他任何东西.这意味着S1,在第3阶段当选为领导者,必须2在第1个插槽中.

(顺便说一句,我花了一分钟才弄清楚你是如何进入这种情况的.)

另外,Raft被称为"Paxos更易理解的版本".我不同意:它似乎有这么多(如果不是更多)角落案例.但是,Raft的作者非常善于让工程师轻松地正确实现某些实用的东西.这与作者如何撰写筏纸有关.