Paxos 与两阶段提交

Posted 2023-02-16

【中文标题】Paxos 与两阶段提交

【英文标题】：Paxos vs two phase commit

【发布时间】：2015-02-02 23:22:12

【问题描述】：

我试图理解 paxos 和两阶段提交之间的区别，作为在多台机器之间达成共识的手段。两阶段提交和三阶段提交很容易理解。 3PC似乎也解决了2PC阻塞的故障问题。所以我真的不明白 Paxos 解决了什么问题。谁能告诉我 Paxos 究竟解决了什么问题？

【参考方案1】：

2-PC 是最传统的事务提交协议，是事务原子性的核心。但它本质上是阻塞的，即如果事务管理器/协调器在两者之​​间发生故障，它将导致协议阻塞并且没有进程会意识到它。修复协调器需要人工干预。

虽然 Paxos 作为分布式共识协议有多个这样的协调者，如果大多数协调者同意事务完成，它就会成为一个成功的原子事务。

您应该阅读https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2003-96.pdf 了解如何以更细化的方式区分这两种协议。在同一篇论文中，Gray 和 Lamport 还介绍了一种协议，即 Paxos 和 2-PC 的组合，以提高性能。

【参考方案2】：

如果事务管理器失败，2PC 会阻塞，需要人工干预才能重新启动。 3PC 算法（有几种这样的算法）试图通过在原来的管理器失败时选举一个新的事务管理器来修复 2PC。

只要大多数进程（管理器）正确，Paxos 就不会阻塞。 Paxos 实际上解决了更普遍的共识问题，因此，它也可以用于实现事务提交。与 2PC 相比，它需要更多消息，但它对管理器故障具有弹性。与大多数 3PC 算法相比，Paxos 呈现出更简单、更高效的算法（消息延迟最小），并且已被证明是正确的。

Gray 和 Lamport 在一篇名为“Consensus on Transaction Commit”的出色 paper 中比较了 2PC 和 Paxos。

（在彼得的回答中，我认为他正在将 2PC 与 2PL（两相锁定）混合在一起。）

【讨论】：

然后第三个是 Raft，它是更轻量级的 Paxos 版本。现在有很多开源系统使用 raft。如Etcd、Consul、Cockroachdb等

Multi-Paxos 处于稳定状态（无故障）具有支持继续处理 f 故障的最小消息数。在一个 3 节点集群中，领导者只需要一次往返即可知道数据在第二个节点，它不需要等待第三个节点的响应。 2PC 还需要与另一个需要往返的节点交换消息。两种算法都可以在下一个值消息中捎带提交消息。所以我认为说 Paxos 需要更多消息并不准确，因为性能在稳定状态下是相当的。