在这种情况下,当我采用Raft的“从不通过计算副本数来提交以前条款中的日志条目”规则时,这会引起真正的问题吗?

时间:2018-12-15 15:35:40

标签: distributed-system consensus raft

我目前正在自己​​实现Raft共识算法,因此遇到了以下问题。 考虑到有4个节点(A,B,C和D),因此日志条目的提交可以超过2票。现在,我们启动集群,并以term = 0选出LeaderA。然后发生以下事情:

  1. 以下B / D断开连接。
  2. 领导者A创建LogEntry X。
  3. 领导者A尝试复制到所有节点,但最终失败,因为只有2个节点(A和C)。
  4. 节点B重新连接并超时,它使用新的term = 1开始选举。
  5. 节点A失去了领导地位,因为它收到了节点B的RequestVote RPC。
  6. 节点B无法赢得选举,因为它没有LogEntryX。因此群集中没有领导者。
  7. 节点A超时,再次被选为Leader。
  8. 领导者A成功将LogEntry X复制到B。
  9. 现在,节点A / B / C具有完全相同的LogEntry X,即(index = 0, term = 0)。但是,根据Raft的论文,组长A不能提交X,尽管它是由自己生成的,并且大多数人都同意X。

      

    筏从不提交前项的日志条目   副本。仅领导者当前任期的日志条目是   通过计算副本数来提交;

  10. 假设没有更多的LogEntry来自客户端要复制,因此LogEntry X未被提交。

我的问题是:

  1. 这是一个真正的问题吗?
  2. 有解决方案吗? 实际上,在SoF上已经有一些帖子强调了此规则的重要性。在此post中,似乎是说我们可以创建X的副本Y,然后复制Y。它是否有效,或者存在一个通用的解决方案?

1 个答案:

答案 0 :(得分:2)

  1. 是的。在第13页的牛皮纸中,您具有以下内容:

  

领导者的完整性   财产保证领导者拥有所有已提交的条目,但是在任期开始时,它可能不知道哪个   那些是。为了找出答案,它需要提交一个条目   它的期限。 Raft通过让每个领导者在其开始时在日志中提交一个空白的无操作条目来解决此问题   项

对于您的情况,在第7步之后,A将创建一个NoOp日志条目,它将成功复制它,将其提交,因此所有先前的条目都将被提交。