database - 两阶段提交 : availability, 可伸缩性和性能问题

Question

我读了很多文章，感到很困惑。

意见一: 2PC 非常高效，交换的消息数量最少且延迟很低。 来源: http://highscalability.com/paper-consensus-protocols-two-phase-commit

意见二: 很难将分布式事务扩展到高级别，而且它们会降低吞吐量。作为2PC guarantess ACID 其复杂的协调算法带来了很大的负担。 来源:http://ivoroshilin.com/2014/03/18/distributed-transactions-and-scalability-issues-in-large-scale-distributed-systems/

意见三: “一些作者声称两阶段提交太昂贵而无法支持，因为 它带来的性能或可用性问题。我们相信最好有 应用程序程序员处理由于过度使用事务而导致的性能问题 当瓶颈出现时，而不是总是围绕缺乏交易进行编码。运行 Paxos 上的两阶段提交减轻了可用性问题。” 来源:http://courses.cs.washington.edu/courses/csep552/13sp/lectures/6/spanner.pdf

意见 4: 2PC 协调器也代表单点故障，这对于关键系统来说是 Not Acceptable ——我相信它是一个协调器。 来源:http://www.addsimplicity.com/adding_simplicity_an_engi/2006/12/2pc_or_not_2pc_.html

前三个观点相互矛盾。第 4 个我认为是正确的。请澄清什么是错误的，什么是正确的。如果能说明原因，那就太好了。

Answer 1

第 4 条陈述是正确的，但可能与您阅读它的方式不同。在2PC中，如果协调器失效，系统就无法进行。因此，通常需要使用像 Paxos 这样的容错协议(protocol)(例如，参见 Gray and Lamport)，这将允许系统在出现故障时安全地进行。

意见 3 应结合 Spanner 论文的其余部分阅读。作者说他们已经开发了一个允许在分布式数据库中进行高效事务的系统，并且他们认为这是系统用户的正确默认权衡。论文中详细介绍了 Spanner 的实现方式，值得一读。请注意，Spanner 只是一种组织协调的方式(一种聪明的方式，理所当然)，而协调是实现可序列化事务所必需的。参见 Gilbert and Lynch一种查看协调限制的方法)。

观点 2 是一种普遍的看法，在现实世界的分布式系统中，事务语义的可用性和丰富性之间确实存在权衡。然而，当前的研究清楚地表明，这些权衡并不像过去描述的那样可怕。参见 this talk by Peter Bailis为研究方向之一。如果您想要真正的串行化或最严格意义上的线性化，您需要遵守特定的协调下限才能实现它们。

观点 1 在技术上是正确的，但在您引用它的方式上不是很有帮助。 2PC 在某种意义上是最优的，但由于可用性权衡，很少天真地实现。许多临时尝试解决这些权衡会导致不正确的协议(protocol)。其他人，如 Paxos 和 Raft，以一些复杂性为代价成功地解决了这些问题。