为什么paxos在mysql组复制跳转prepare阶段？
Why paxos in mysql group replication jump prepare phase？
我在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会跳过准备阶段直接发送接受请求
我想知道为什么，非常感谢。
如果你看论文 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.
这就是说领导者仅在领导者故障转移期间发出准备。之后它流式传输接受消息。然后它有 "optimal messaging" 因为领导者只需要一次往返就知道选择了一个值（接受消息及其确认）。
在三节点集群中，领导者瞬间自我接受，然后只需要第二个节点的接受确认即可获得多数。然后它知道该值已被选择，而不必等待来自第三个节点（可能已关闭）的响应。这是你能得到的最有效的方法。已知该值在具有强一致性的第二节点处被接受。
鉴于 paxos 是如何工作以获得最大效率的，我们应该期望 mysql xcom 有一种模式可以在稳定状态下跳过准备消息阶段。
您可以在我的博客上阅读更多关于 Paxos Made Simple 技术的信息 here。
您可能有兴趣了解 Paxos 的最新发展，其中您不需要使用 FPaxos and tricks like the even nodes optimization 在集群中接受消息的多数响应。
我在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会跳过准备阶段直接发送接受请求
我想知道为什么，非常感谢。
如果你看论文 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.
这就是说领导者仅在领导者故障转移期间发出准备。之后它流式传输接受消息。然后它有 "optimal messaging" 因为领导者只需要一次往返就知道选择了一个值（接受消息及其确认）。
在三节点集群中，领导者瞬间自我接受，然后只需要第二个节点的接受确认即可获得多数。然后它知道该值已被选择，而不必等待来自第三个节点（可能已关闭）的响应。这是你能得到的最有效的方法。已知该值在具有强一致性的第二节点处被接受。
鉴于 paxos 是如何工作以获得最大效率的，我们应该期望 mysql xcom 有一种模式可以在稳定状态下跳过准备消息阶段。
您可以在我的博客上阅读更多关于 Paxos Made Simple 技术的信息 here。
您可能有兴趣了解 Paxos 的最新发展，其中您不需要使用 FPaxos and tricks like the even nodes optimization 在集群中接受消息的多数响应。