【问题标题】:How does raft handle committing entries from previous one?raft 如何处理前一个提交的条目?
【发布时间】:2019-12-10 17:48:08
【问题描述】:

在筏 paper 第 5.4.2 节

如果领导者之前崩溃 提交一个条目,未来的领导者将尝试 完成复制条目。但是,领导者不能立即 得出结论,上一学期的条目是 一旦它存储在大多数服务器上就提交。可能存在存储旧日志条目的情况 在大多数服务器上,但仍然可以被 未来的领袖。

作者提到要避免上述情况

为了消除图 8 中的问题,Raft 从不通过计数来提交以前条款的日志条目 复制品。仅记录来自领导者当前的条目 通过计算副本来提交术语;一次进入 从当前任期开始,一直以这种方式承诺, 那么所有先前的条目都是间接提交的,因为 日志匹配属性。

但不会还是会出现同样的问题吗?

鉴于作者提供的以下情况

S5 被选为领导者时,它只会查看其当前提交的日志,即(term3, index1),这将覆盖所有关注者中的term2 条目。

让领导者查看自己提交的日志如何解决问题?

【问题讨论】:

    标签: algorithm distributed consensus raft leader


    【解决方案1】:

    阅读这张图片的标题。 (d) 和 (e) 都是对 (a)、(b) 和 (c) 生成的日志状态的可能解决方案。问题是,即使在 (c) 中条目 (2, 2) 被复制到集群的大多数成员,这说明当在 (d) 中选择 S5 时它仍然可能被覆盖。因此,解决方案是只允许节点提交他们自己任期内的条目。换句话说,在大多数节点上复制一个条目并没有 相等的承诺。在 (c) 中,条目 (2, 2) 被复制到集群的大部分,但因为它不在领导者的任期内(至少 4 个),所以它没有被提交。但是在 (e) 中,在领导者复制了其当前任期 (4) 中的条目之后,这防止了 (d) 中的情况发生,因为 S5 不能再被选举为领导者。

    【讨论】:

    • OP 在我回答类似问题时问我,但我不知道答案。为了不等待 OP,让我问你同样的问题:假设 S1 将 4 复制到 S2 和 S3,如图所示,认为它已提交,同时与其他节点断开。 S2 和/或 S3 如何知道阻止 S5 成为领导者?
    • @starikoff 读取协议中描述的接收者的实现,候选人不会获得追随者的投票,除非其日志至少没有与追随者的日志保持同步。
    【解决方案2】:

    在 S1 复制条目 4 后,其任期高于 2 和 3。S5 将不再被选为领导者,因为 Raft 的领导者选举策略:

    Raft 通过比较日志中最后一个条目的索引和期限来确定两个日志中哪一个更新。如果日志具有不同术语的最后条目,则具有较晚术语的日志是最新的。如果日志以相同的期限结束,则以较长的日志为准。

    因此,在我看来,(e) 中附加的日志条目 4 隐含地提升了它之前的所有条目的术语。因为我们只关心term或者最后一个entry,而不是entry 2。

    这就像 Paxos 阶段 2 中提议者所做的一样:

    如果提议者从大多数接受者那里收到对其准备请求(编号为 n)的响应,那么它会向这些接受者中的每一个发送一个接受请求,以获取编号为 n 且值为 v 的提议,其中 v 是响应中编号最高的提案,如果响应没有报告提案,则为任何值。

    也就是说,用更高的提议数提议学习值 2。

    【讨论】:

      【解决方案3】:

      我认为图 8 (d) 和 (e) 中的两种情况在 Raft 中都是合法的,因为论文说:

      为了消除图 8 中的问题,Raft 永远不会通过计算副本来提交先前条款的日志条目。只有来自领导者当前任期的日志条目通过计算副本来提交。

      在图 8(d) 中,term 2 的条目不在领导者 S5 的本地日志中,并且它们没有提交到状态机。可以用 term 3 的条目覆盖它们。通过计算副本的数量,只有领导者当前日志中的条目才有资格被视为已提交。

      【讨论】:

        【解决方案4】:

        如果我们允许提交上一个任期的条目,在(c) 之后,编号为2 的条目将被提交。之后,如果3被选为leader,它将覆盖已提交的2。因此,S5S1 将执行不同的命令。为了防止这种情况发生,我们不允许2 提交。这样,在所有状态机中执行的命令就会变得一致。

        【讨论】:

          【解决方案5】:

          我认为问题是领导者在少数追随者将日志应用到状态机后崩溃了。 图中(c)中,Leader已经将term 2的日志复制到了一半以上的节点上,然后Leader更新commitIndex为2并发送心跳。而在leader crash之前,只有S2收到心跳并将term 2的日志应用到状态机。根据论文,S5可以通过S3和S4的投票成为新的leader,并尝试将term 3的日志附加到S2 〜S4。但是,这个操作不应该被允许,因为 S2 已经将索引 2 处的日志应用到状态机。 似乎 Raft 没有涵盖这种情况

          【讨论】:

          • 我想我知道问题出在哪里。在第 4 学期,S1 不会发送提交索引为 2 的 rpc,因为它不知道第 2 学期的日志条目是否已复制到主要节点。
          猜你喜欢
          • 2019-07-23
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2017-07-07
          • 2012-04-22
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多