大家好，我是Tony Bai。
欢迎来到《分布式系统：原理、哲学与实战》微专栏的第七讲。
在上一讲中，我们征服了“分区”这片广阔的疆域。通过将数据“分而治之”，我们获得了构建海量系统的能力。但我们也留下了一个最棘手的“悬念”：
如果一次业务操作，需要原子性地修改位于不同分区的数据，我们该怎么办？
想象一个经典的银行转账场景：用户 Gopher 要从他在分区 A 的储蓄账户，转账 100 元到他在分区 B 的信用卡账户。这个操作包含两个步骤：
储蓄账户（分区 A）扣款 100 元。
信用卡账户（分区 B）入账 100 元。
我们对这个操作有一个神圣的、不可违背的要求：原子性 (Atomicity)。这两个步骤必须要么全部成功，要么全部失败。我们绝不能接受扣款成功但入账失败（钱没了），或者扣款失败但入账成功（天降横财）的情况。
在单机数据库中，BEGIN TRANSACTION...COMMIT语句优雅地为我们解决了这个问题。但现在，数据被分割在两个独立的、通过不可靠网络连接的物理节点上。我们如何在一个被“分裂”的世界里，重塑“原子性”的辉煌？
今天，我们将深入探讨对这个问题最早、也是最经典的回答——**两阶段提交协议 (Two-Phase Commit, 2PC)**。我们将看到，它是一个试图在分布式世界中，完美复刻单机事务的“理想主义”英雄。
然而，当这个“英雄”暴露出其致命的脆弱性时，一场旨在拯救它的“改良运动”也随之展开，催生了更复杂的**三阶段提交协议 (Three-Phase Commit, 3PC)**。
本章，我们将共同见证这场围绕“完美原子性”展开的、长达数十年的执着追求与艰难挣扎。我们将剖析 2PC 的伟大构想与悲壮缺陷，并审视 3PC 的改良尝试为何最终也未能成为完美的答案。
我们先从两阶段提交协议( 2PC )开始。
2PC 协议详解：一场由“协调者”主导的投票
两阶段提交引入了两个核心角色：
协调者 (Coordinator):事务的发起者和最终决策者。在我们的例子中，可以是一个专门的事务管理服务，或是发起转账请求的应用服务器。
参与者 (Participants):所有涉及该事务的数据节点。在我们的例子中，就是分区 A 和分区 B。
顾名思义，整个协议分为两个阶段：准备阶段 (Prepare Phase)和 提交阶段 (Commit Phase)。
