分布式事务：让多方协作像一场婚宴那样有序

可视化演示

动态展示2PC两阶段提交、3PC三阶段提交、Saga补偿事务与TCC确认取消四种方案对比。

事务基础概念

假设你一个人在家做一桌菜：买菜、洗菜、炒菜、上桌，全由你掌控，任何环节出错你都能立刻补救——这是“单机事务”的舒适区。但在婚宴里，你只是总指挥，后厨、花艺、场地方各有各的账本。把“一个人的事”拆给多方协作，问题立刻浮现：他们没有共享的厨房，无法像你一样随时回退。

数据库中的“事务”指一组要么全部成功、要么全部失败的操作，靠四个性质保证：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），合称 ACID。单体数据库里，一个事务可以覆盖多张表；但分布式系统里，数据分散在不同服务、不同数据库中，一次业务操作要跨越多个“账本”，本地事务就有心无力了。

分布式系统还要面对三个现实约束——网络分区、机器宕机、时钟偏差。这些约束催生了 CAP 定理：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），最多只能同时满足两个；而网络分区无法避免，所以工程上真正要做的，是在“强一致”与“可用性”之间二选一。弱化强一致、接受“最终一致”，是构建高可用系统的常见妥协。

就像婚宴策划要先定调“追求仪式感还是灵活性”，分布式事务的起点也是先想清楚一个问题：你到底能不能接受短暂的不一致？这个答案，将决定后面所有方案的选择。

两阶段提交

最“仪式感”的做法：总指挥群发请柬——“10 月 1 日有档期吗？”后厨回“能”，花艺回“能”，场地方回“能”，好，锁定档期，统一通知“开席”；只要有任何一个说“不能”，全部取消预订。这就是二阶段提交（2PC）：把“协调多方”简化成“问一遍、定一次”。

2PC 引入一个协调者（总指挥）和若干参与者（供应商）。第一阶段“投票阶段”：协调者向所有参与者发送准备请求，参与者锁定相关资源、写好回滚日志后，回复“就绪”或“中止”。第二阶段“提交阶段”：协调者收集投票，若全票就绪则广播提交指令；只要有一票中止，则广播中止指令。

2PC 能提供强一致性，代价却是两个著名缺陷：一是同步阻塞——参与者在投票后一直持有资源锁，直到收到最终指令，期间其他事务被挡在门外；二是协调者单点故障——如果协调者在第二阶段宕机，参与者既等不到提交也等不到中止，只能无限期阻塞，甚至出现部分已提交、部分未提交的不一致。

婚宴上，大家为了等总指挥一声令下，从上午十点干等到下午三点：厨师不敢开火、花艺不敢撤棚。如果总指挥中途晕倒，这顿婚宴就永远卡在“备而不开”的僵局里——这就是 2PC 最真实的写照。

三阶段提交

为了不让大家干等，总指挥把流程改成三步：先问“能开席吗？”；得到肯定后发“预开席”，让厨师先把菜备好；最后才发“正式开席”。更重要的是，每位供应商都戴了手表——如果总指挥失联太久，他们不再傻等，而是按约定自行决定去留。这就是三阶段提交（3PC）。

3PC 在 2PC 的两阶段之间插入一个预提交阶段，形成 CanCommit → PreCommit → DoCommit 三段式。CanCommit 只做可行性探测，不锁资源；PreCommit 让参与者真正准备资源并回复确认；DoCommit 才正式提交。每一阶段协调者都可能因超时中止，参与者同样有超时机制：在预提交后如果收不到正式提交指令，会基于“多数派已准备”的事实自行提交或回滚。

3PC 用超时机制解决了 2PC 中协调者故障导致的无限阻塞，也缩小了阻塞窗口；但它并非完美：为了多一轮消息交互，正常路径的延迟比 2PC 更高；而且在极端网络分区下仍可能“脑裂”——部分参与者超时自行提交，另一部分超时自行回滚，数据照样不一致。因此工程上 3PC 用得并不多，更多是借鉴它“超时 + 多阶段确认”的思想。

给每个人都戴上手表，确实避免了“干等总指挥”；但如果大家等到的信号不一致——有人听到“开席”上了菜，有人听到“取消”撤了桌——那这场婚宴的混乱，可能比等待等出来的更糟。

Saga 模型

换一种思路：婚宴不搞“统一开席”，而是十道菜一道一道上。每上一道，就当作“已成事实”；如果第四道主菜烧糊了，就按相反顺序把第三道、第二道、第一道撤下去，让宾客当作没吃过这道菜。这就是 Saga：用“撤菜”代替“锁桌”。

Saga 把一个大型分布式事务拆成一组有顺序的本地事务 $T_1, T_2, \dots, T_n$，每个 $T_i$ 都在自己的服务内独立提交；同时为每一步提前准备一个“补偿事务” $C_i$。一旦第 $k$ 步失败，就逆序执行 $C_{k-1}, \dots, C_1$，把已生效的操作一一撤销。

Saga 不持有长事务锁，并发性能和可用性远高于 2PC；代价是一致性弱化为“最终一致”——中间状态对外可见，业务必须容忍。两种协调方式：编排式（Choreography），每个服务完成后发事件驱动下一个服务，去中心化；协同式（Orchestration），由中央编排器集中调用各服务并负责补偿编排。电商下单、多仓拆单等长链路场景常用 Saga。注意，补偿事务不是简单地“删数据”，而是要设计成业务级的逆向操作——比如把库存加回“可用额度”，而不是删掉流水记录。

“撤菜”听起来轻松，其实有成本：后厨的食材钱、花艺的损耗退不回来，还得向宾客道歉。所以 Saga 的补偿事务必须提前设计好，甚至要有人工对账任务兜底，才能保证最终一致。

TCC 模式

再回到婚宴筹备的“订食材”环节。精明的总指挥不会立刻全款下单，而是先“锁档期”：告诉供应商“10 月 1 日的食材我预留了，先别卖给别人，但我还不付款”。等后厨、花艺、场地方全都锁定成功，才统一“确认下单”付款；任何一个环节锁失败，就通知所有人“取消预留”。这就是 TCC。

TCC（Try-Confirm-Cancel）把业务操作拆成三个接口：Try——做资源检查与预留，不真正改动业务数据；Confirm——真正执行业务，让预留的资源生效；Cancel——释放资源，回到 Try 之前的状态。协调者先调用所有参与者的 Try 接口，全部成功再逐个调 Confirm；任一失败则逐个调 Cancel。

相比 2PC，TCC 不用全局锁，而是把“锁”放进了业务语义——比如冻结金额、预占库存——性能和灵活性都好得多，非常适合金融转账、库存扣减等场景。但它把一致性保证转嫁给了业务方：三个接口都要实现幂等；还要处理“空回滚”（Cancel 到达时 Try 还没成功，要安全返回而非报错）和“悬挂”（Try 迟到于 Cancel，要拒绝执行）等边界问题，实现成本不低。

锁定档期、确认成交、取消释放——这套玩法像极了现代婚宴的预订制：钱没付、位置不丢，任何一个供应商没档期就全部取消。业务规则越清晰，TCC 就越顺手；前提是每个供应商都愿意配合你的“锁档”逻辑。

选型决策框架

办婚宴没有唯一正确答案：传统家庭要排场，宁可让宾客等也要全场一致上菜（对应 2PC/3PC）；新派家庭讲究体验，菜一道道上，哪道翻车也能圆场（对应 Saga）；宴会厅预订讲究档期锁定，钱和位置都不含糊（对应 TCC）。选型，本质是看清“你办的是什么样的宴”。

四个方案在一致性、延迟、可用性、实现成本之间各有取舍：2PC/3PC 提供强一致，但阻塞风险高；Saga 提供最终一致、可用性高，但没有隔离性，中间态可见；TCC 提供业务层面的最终一致、性能好，但要求业务方实现三个接口并处理幂等与空回滚。选型框架可以浓缩为三个问题：业务能容忍短暂不一致吗？事务链路长不长、并发高不高？团队能承担多少实现成本？

具体到生产场景：金融转账、账务系统通常选 TCC（冻结/解冻资金）或 2PC（低并发的内部链路）；电商下单、库存与支付多服务协作通常选 Saga（协同式编排）来保证最终一致和可用性；中小团队想快速落地，优先考虑 Saga 编排加消息对账。另外，任何分布式方案都无法 100% 消除不一致窗口，必须配套事务消息或定时对账任务兜底。

把四种方案放在婚宴的时间轴上：2PC 是“全场齐开席”的仪式派，3PC 是“预演防呆”的稳妥派，Saga 是“随上随撤”的灵活派，TCC 是“先锁后付”的商务派。看清自家宴席的需求再选方案，你就能在风暴中稳稳掌勺。

AI 应用场景

Python 演示

# 婚宴筹备仿真: 对比 2PC 与 Saga 的失败恢复import random  class Vendor:    """一位供应商: 后厨 / 花艺 / 场地方"""     def __init__(self, name, fail_rate):        self.name = name        self.fail_rate = fail_rate     def prepare(self, job):        """尝试完成一项准备工作, 按概率失败"""        if random.random() < self.fail_rate:            print("  [失败] " + self.name + " 无法完成: " + job)            return False        print("  [完成] " + self.name + ": " + job)        return True     def undo(self, job):        print("  [补偿] " + self.name + " 撤销: " + job)  def run_2pc(vendors, jobs):    """2PC: 先投票探测, 全部同意才统一执行"""    print("== 2PC 开始 ==")    for v in vendors:        if not v.prepare("档期探测"):            print("== 2PC 结果: 有人反对, 全局回滚 ==")            return    print("== 2PC 结果: 全票通过, 统一提交 ==")    for v, job in zip(vendors, jobs):        v.prepare(job)  def run_saga(steps):    """Saga: 逐道执行, 失败则逆序补偿"""    print("== Saga 开始 ==")    done = []    for step in steps:        name, do, undo_job, undo = step        if not do():            print("== " + name + " 失败, 开始逆序补偿 ==")            for _, _, uj, u in reversed(done):                u(uj)            return        done.append(step)    print("== Saga 结果: 全部成功 ==")  if __name__ == "__main__":    random.seed(42)    chef = Vendor("后厨", 0.05)    florist = Vendor("花艺", 0.30)    run_2pc([chef, florist], ["准备凉菜", "布置桌花"])    print()    steps = [        ("凉菜", lambda: chef.prepare("准备凉菜"), "凉菜", chef.undo),        ("桌花", lambda: florist.prepare("布置桌花"), "桌花", florist.undo),    ]    run_saga(steps)

1. class Vendor:用“供应商”对象模拟婚宴中的后厨、花艺等服务方，各自持有失败概率。
2. if random.random() < self.fail_rate:用随机数模拟服务方“今天掉链子”的概率，让失败可复现。
3. def run_2pc(vendors, jobs):2PC 协调流程：第一阶段先探测每家能否就绪。
4. if not v.prepare("档期探测"):投票阶段只要有一家返回失败，立即全局回滚。
5. for v, job in zip(vendors, jobs):全票通过后进入第二阶段，统一执行真实业务。
6. def run_saga(steps):Saga 编排器：把每一步与它的补偿动作打包成元组。
7. name, do, undo_job, undo = step解包四元组：步骤名、执行函数、补偿名、补偿函数。
8. done.append(step)记下已成功的步骤，供后续补偿使用。
9. for _, _, uj, u in reversed(done):失败时逆序遍历历史步骤，逐个执行补偿事务。
10. random.seed(42)固定随机种子，让演示结果可复现，便于讲解。

常见误区

面试题