为什么mysql组复制中的paxos会跳转准备阶段？；

我在proposer_任务（xcom_base.c）中看到了这样的代码段

这里的

threepahse

是

int const threephase=0

和

force_delivery==0

push\u msg\u eq

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

但push_msg_2p将跳过准备阶段，直接发送接受请求

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

如果你看报纸第10页，第3段说：

新选择的引线对无限多个实例执行阶段1 协商一致算法的应用[…]

第4段：

因为领导人的失败和新领导人的选举应该是罕见的 事件，执行状态机命令的有效成本 就命令/价值达成共识的成本是 仅执行一致性算法的第2阶段。它可以显示出来 Paxos一致性算法的第2阶段具有尽可能小的可能性 出现故障时达成一致的任何算法的成本。 因此，Paxos算法本质上是最优的

这意味着领导者仅在领导者故障切换期间发布prepare。之后，它接受消息流。然后它就有了“最佳消息传递”，领导者只需要一次往返就知道选择了一个值（接受消息及其确认）

在一个三节点集群中，一个领导者自己即时接受，然后只需要第二个节点的一个接受确认就可以拥有多数。然后，它知道选择了该值，而无需等待第三个节点的响应（该节点可能已关闭）。这是你能得到的最有效的。已知该值在具有强一致性的第二个节点上被接受

考虑到paxos是如何获得最大效率的，我们应该期望mysql xcom具有一种在稳态下跳过准备消息阶段的模式

你可以在我的博客上读到更多关于Paxos的简单技术

---

您可能有兴趣了解Paxos的最新发展，在Paxos中，您不需要使用和类似的技巧在集群中接受消息的多数响应

2p表示两阶段提交，3p表示三阶段提交吗？在我看来，这就是它的样子。@MichaelDeardeuff我认为2p意味着在这里接受和学习，3p意味着准备、接受和学习learn@MichaelDeardeuff看起来mysql去年升级到了Paxos

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);
}