为什么paxos在mysql组复制跳转准备阶段？

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将跳过准备阶段并直接发送接受请求。

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

Answer 1

如果你看看报纸帕克斯第10页第3段说：

新选择的领导者执行第一阶段的无限多个实例的共识算法.

然后第4段：

由于领导人的失败和新领导人的选举应该是罕见的事件，执行状态机命令的有效成本--即就命令/值达成共识--是只执行协商一致算法第二阶段的成本。结果表明，在存在故障的情况下，Paxos协商一致算法的第二阶段具有最小的可能代价。因此，Paxos算法本质上是最优的。

这就是说，一个领导者只会在领导失败时做好准备。在此之后，它流接受消息。然后，它有了“最佳消息传递”，即领导者只需要一次往返就可以知道所选择的值(接受消息及其确认)。

在一个三节点集群中，领导者自己立即接受，然后只需要从第二个节点获得一个接受确认即可获得多数。然后，它知道值是被选择的，而不必等待来自第三个节点的响应(可能是向下的)。这是你所能得到的最有效的。该值已知在具有强一致性的第二个节点上被接受。

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

你可以在我的博客这里上读到更多关于Paxos制作简单技术的文章。

您可能有兴趣了解Paxos的最新发展，您不需要使用FPaxos和偶节点优化之类的技巧对集群中的接受消息作出多数响应。