Multi-Paxos把选主视为Prepare阶段，任期内日志同步只需Accept

Basic Paxos理论模型要求每条日志都独立跑完整的两阶段协议（3次网络交互加2次本地持久化），这个代价在实际工程场景下（比如数据库Redo Log持续高频同步）是不可接受的，Multi-Paxos给出的核心优化正是建立在[[Multi-Paxos选主的本质：关心谁赢得了多数派应答，而非达成决议内容]]的基础上：既然选主本身就是走了一轮Paxos，那么可以把这一轮选主看作是对”Leader任期内所有即将产生的日志”一次性统一执行了Prepare阶段——因为Prepare阶段本身不需要携带具体提案内容，只需要确立一个ProposalID并获得多数派对这个ID的承诺，所以选主时产生的这个ProposalID，可以被后续整个任期内的所有日志同步复用，不需要每条日志各自重新走一遍Prepare。这样一来，Leader任期内的日志同步就被简化成只需要执行Accept阶段——各备机在执行Accept时依然要遵守之前在Prepare阶段做出的”两个承诺”，保证正确性不受影响。这个优化还可以再进一步简化：既然”当选Leader”必须立即写一条日志来确认自己的身份，而选主这一轮Paxos本身产生的决议内容并没有实际意义（真正有意义的是”谁赢得了多数派”这件事本身，见前述），选主过程甚至可以进一步简化为只执行Prepare阶段而不用执行Accept阶段。这套简化思路揭示了一条通用的协议工程优化模式：当同一个安全机制（这里是Prepare阶段建立的ProposalID和承诺）需要被反复应用于一系列相关的操作时，如果能找到一个合理的边界（这里是”Leader的一个任期”）把这个机制的作用范围从”单次操作”扩展到”一批操作”，就能把原本每次都要付出的协议开销，摊薄成只需要付出一次。