为何MySQL组复制中的Paxos跳过Prepare阶段？

First, let's ground this in the code snippet you shared:

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

With threephase = 0 and force_delivery = 0, the code takes the push_msg_2p path—skipping the Prepare phase and sending an Accept request directly. Here’s why this design makes sense:

• Optimizing for the steady-state (stable leader) case
  In most production systems running Paxos, leaders stay stable for long periods (failures are the exception, not the rule). When a leader is confident it’s still the valid, active leader (e.g., it’s receiving regular heartbeats from a quorum of acceptors), the Prepare phase’s core job—ensuring no other proposer has locked in a higher-numbered value—becomes redundant. Skipping it cuts out an entire round-trip of network latency for each consensus operation.

• Cutting down on message overhead
  Standard 3-phase Paxos requires two round trips (Prepare → Promise, then Accept → Accepted). By skipping Prepare, you halve the number of messages exchanged in the common case. This is a huge win for throughput, especially in high-volume systems where every extra message adds up.

• Implicit validation via the Accept phase
  Even without an explicit Prepare, the Accept request itself acts as a lightweight check. Acceptors will only honor an Accept request if they haven’t already promised to a higher-numbered proposer. If the leader is still valid, the quorum will accept immediately. If there is a competing proposer (a rare edge case), some acceptors will reject, and the leader can fall back to the full 3-phase flow using the threephase or force_delivery flags you noticed.

• Following Fast Paxos principles
  This is a classic example of Fast Paxos, a variant designed to optimize for low-contention scenarios. The tradeoff is that if contention does pop up (multiple proposers vying for leadership), you might have to retry with the full protocol—but in most steady-state environments, this cost is negligible compared to the performance gains.

At the end of the day, this is a pragmatic optimization: prioritize speed and efficiency for the common case, with safeguards (the threephase and force_delivery flags) to fall back to the full, safe protocol when needed.

内容的提问来源于stack exchange，提问作者jfxu