mysql - 为什么paxos在mysql group replication中跳转prepare阶段？

Question

我在proposer_task(xcom_base.c)中看到这样的代码段

if(threephase || ep->p->force_delivery){
    push_msg_3p(ep->site, ep->p, ep->prepare_msg, ep->msgno, normal);
}else{
    push_msg_2p(ep->site, ep->p);
}

threepahse 是 int const threephase = 0 和 force_delivery == 0 在这里

push_msg_eq 是正常的 paxos，包括准备、接受和学习阶段

但是push_msg_2p会跳过prepare阶段直接发送accept请求

我想知道为什么，非常感谢。

Answer 1

如果你看论文Paxos Made Simple第 10 页第 3 段说:

A newly chosen leader executes phase 1 for infinitely many instances of the consensus algorithm [...]

然后是第4段:

Since failure of the leader and election of a new one should be rare events, the effective cost of executing a state machine command—that is, of achieving consensus on the command/value—is the cost of executing only phase 2 of the consensus algorithm. It can be shown that phase 2 of the Paxos consensus algorithm has the minimum possible cost of any algorithm for reaching agreement in the presence of faults. Hence, the Paxos algorithm is essentially optimal.

这就是说，领导者仅在领导者故障转移期间发出准备。之后它流式传输接受消息。然后它具有“最佳消息传递”，因为领导者只需要一次往返就知道选择了一个值(接受消息及其确认)。

在一个三节点集群中，一个领导者瞬间 self 接受，然后只需要一个来自第二个节点的接受确认就可以拥有多数。然后它知道该值已被选择，而不必等待来自第三个节点(可能已关闭)的响应。这是你能得到的最有效的方法。已知该值在具有强一致性的第二节点处被接受。

鉴于这就是 paxos 工作以获得最大效率的方式，我们应该期望 mysql xcom 有一种模式可以在稳定状态下跳过准备消息阶段。

您可以在我的博客上阅读更多关于 Paxos Made Simple 技术的信息 here .

您可能有兴趣了解 Paxos 的最新发展，您不需要使用 FPaxos 在集群中接受消息的多数响应。和像 even nodes optimization 这样的技巧.