分布式提交与共识

分布式提交和共识协议允许多个数据库节点原子性地就事务结果和操作的一致顺序达成一致，即使在节点和网络可能发生故障的情况下也是如此。

Definition

原子提交是确保分布式事务中所有参与节点同意提交或中止事务的问题；共识是更普遍的问题，即分布式节点在面对故障时就单个值或有序日志达成一致，用于保持数据库副本的一致性。

Scope

本主题涵盖跨站点事务的原子提交——两阶段提交协议、其阻塞弱点以及非阻塞三阶段提交——以及用于保持复制状态机和提交日志一致的共识协议（Paxos、Raft）。它将这些机制视为数据库中保证原子性和副本一致性的角色。它将共识、故障模型和不可能性结果的通用分布式系统理论推迟到分布式计算主题中，仅引用而不重复。

Core questions

• 两阶段提交如何实现跨节点的原子提交？
• 为什么两阶段提交会阻塞，三阶段提交如何解决这个问题？
• Paxos和Raft等共识协议如何保持副本之间的一致性？
• 共识在复制数据库中与原子提交有何关系？
• 故障和网络分区如何影响这些协议提供的保证？

Key concepts

• 原子提交
• 两阶段提交（2PC）
• 协调者和参与者
• 阻塞和协调者故障问题
• 三阶段提交（3PC）
• Paxos
• Raft
• 复制日志/状态机复制

Key theories

两阶段提交

协调者要求所有参与者准备（投票），然后，只有当所有参与者都投赞成票时，才通知它们提交；该协议保证原子性，但如果协调者在参与者不确定时发生故障，则会阻塞。

非阻塞提交

三阶段提交增加了一个预提交阶段，以便即使协调者发生故障，参与者也能达成一致的决定，从而在某些故障假设下消除了两阶段提交的阻塞行为。

复制状态的共识

Paxos和更易于理解的Raft允许一组副本在面对崩溃时就操作的有序日志达成一致，从而提供了现代数据库用于复制提交决策和配置的容错一致性。

Clinical relevance

分布式提交和共识是多节点数据库可靠性的基础：它们确保涉及多个分片的事务要么全部提交，要么全部不提交，并且复制系统在故障后不会出现分歧，这对于金融和全球分布式数据系统的正确性至关重要。

History

两阶段提交是分布式原子性的早期标准；Skeen和Stonebraker在1983年分析了其阻塞行为，并推动了三阶段提交。Lamport的Paxos（1998年发表）提供了容错共识，而Raft（Ongaro和Ousterhout，2014年）提供了一种更易于理解的替代方案；两者现在都是广泛使用的分布式数据库中复制的基础。

Debates

复制事务的原子提交与共识

两阶段提交保证原子性但在协调者故障时会阻塞，而基于共识的复制以更高的成本容忍故障；系统设计者争论如何结合提交和共识，以在复制、分区数据中同时获得原子性和可用性。

Key figures

• Leslie Lamport
• Dale Skeen
• Diego Ongaro
• John Ousterhout

Seminal works

• lamport1998
• skeen1983
• ongaro2014

Frequently asked questions

为什么两阶段提交会阻塞，这是个问题吗？

如果协调者在参与者投票提交后但在它们得知决定之前发生故障，这些参与者就会被锁住，无法安全地自行提交或中止。这种阻塞会占用资源，直到协调者恢复，这就是为什么开发了三阶段提交和基于共识的方法来减少或消除它。

共识与原子提交有何不同？

原子提交需要一致同意才能提交——任何一个否决或故障都可能导致中止。共识只需要多数节点就一个值达成一致，并且可以在少数节点发生故障的情况下继续进行。数据库使用原子提交进行跨分片事务，并使用共识来保持每个分片的副本一致性。