分布式事务：Saga长事务模式——一场跨城旅行的退订哲学

可视化演示

观察编排式与协同式Saga的执行流程，以及某步失败时逆序补偿回滚的过程，理解本地事务拆解与最终一致性，可切换三种模式。

Saga核心思想

想象你计划一场“东京→京都→大阪”的跨城旅行。机票、温泉酒店、岚山小火车、大阪民宿，是四份完全独立的订单——每份订单一旦确认就真实生效，没有哪个“超级系统”能把它们捆成一份不可拆分的合同。可台风来了，小火车停运，你只能对着已确认的订单，一间间退、一张张退，而且必须严格按相反顺序。

分布式系统里的跨服务业务，就是这个处境。一次订单创建，可能要调用订单服务、库存服务、支付服务、物流服务，四个服务各有各的数据库，根本无法放进同一个数据库事务。1987 年，Hector Garcia-Molina 发表了 Saga 模式的经典论文：把长事务拆成一串独立提交的本地事务，不求“同生共死”，只求失败时能“有序退场”。

一个 Saga 由正向执行序列 T1→T2→……→Tn 和配套的补偿序列 C1→C2→……→C(n-1) 组成。每个 Ti 是真实提交的本地事务；当 Tk 失败时，Saga 放弃后续事务，转而依次执行 C(k-1)→……→C1。这里有个关键认知：补偿不是回滚——Ti 已经 COMMIT，数据已对外可见，C_i 必须是一笔新的、能抵消 Ti 业务后果的动作。比如“扣款”的补偿是“退款”，“扣库存”的补偿是“回补库存”。

回到旅行：小火车停运后，你退民宿、退温泉酒店、退机票，每一步都是真实发生的“反向订单”。Saga 的哲学正源于此——不假装什么都没发生，而是承认每个已提交的事务，再用一系列新的业务动作，让整体状态回到“好像这趟旅行没发生过”。

一致性模型

订四份旅行订单时，你永远不会看到“四份同时确认”的瞬间。可能机票已出票、酒店显示“处理中”、小火车“出票中”、民宿还在等支付回调。整个过程中，系统对外呈现的是一堆相互矛盾的中间状态——这不是故障，而是分布式世界的常态。

传统 ACID 事务要求原子性（Atomicity）和隔离性（Isolation），但跨服务场景受 CAP 定理约束：网络分区时，必须在“可用性”和“一致性”之间二选一。Saga 选择拥抱 BASE——基本可用（Basically Available）、软状态（Soft state）、最终一致（Eventually consistent）。它放弃了 ACID 的原子性，也放弃了隔离性。

在 Saga 中，任何时刻，外部观察者都可能看到“部分提交、部分未提交”的中间状态。系统承诺的是：只要正向链路全部成功，或补偿链路执行到底，状态就会收敛到某个确定的目标。这个从不一致到一致的“收敛过程”，就是最终一致性。设计业务时要让上层容忍这种中间态，比如订单页允许出现“支付中”。

就像旅行途中你不断刷手机，看到订单状态七零八落，但旅行结束后所有订单要么全部确认过、要么全部退款到账，页面不再有任何“处理中”。Saga 保证的是终局，而不是过程。

编排式实现

你不想自己打四通电话，于是委托了一位旅行管家。管家手里有一张行程单，按顺序打电话：先确认机票，再订酒店，再订小火车。哪一步出问题，管家立刻按相反顺序打退订电话，而你只需要跟管家一个人沟通，出了纠纷也有一个人可以追责。

这就是编排式（Orchestration）Saga。系统中有一个中央协调器（Orchestrator），它知道完整流程，向各个服务发送“执行指令”，再根据返回结果决定下一步：继续执行 T(i+1)，还是转入补偿链路 C(i-1)→……→C1。每个 Saga 实例在协调器里都有明确的状态，例如 INIT、T1_DONE、T2_FAILED、COMPENSATING、FINISHED。

协调器通常用状态机实现：每收到一个事件，状态机做一次转移，并持久化当前状态以便崩溃恢复。优点是控制集中、流程显式、容易调试和监控；缺点是协调器承载全部流程逻辑，可能成为单点，需要高可用部署，且服务间多为同步调用，耦合度偏高。

旅行管家把所有行程记在笔记本上，你从不操心细节。编排式的价值就在于“有一个看得见全流程的大脑”，出了任何问题都可以摊开笔记本复盘：哪一步、为什么、补偿了没有、卡在哪个服务。

协同式实现

另一种风格是“接力棒式旅行”：没有管家，酒店前台确认完你的入住后，顺手给旅行社发条消息：“客人到了，请安排明天的行程。”旅行社完成后，再给民宿发消息：“行程已安排，请备好房间。”如果某站发现接待不了，就一路往回传话取消。指挥权不在任何人手里，而在消息本身。

这就是协同式（Choreography）Saga：没有中央协调器，各服务通过事件总线异步交互。每个服务订阅自己关心的事件，完成本地事务后发布新事件，下一个服务被事件“唤醒”继续执行，形成一条事件链。

协同式的优点是服务间松耦合、无单点、扩展性好，适合高并发事件流场景；缺点是流程逻辑散落在各服务的事件处理器中，全局视图缺失，排查问题必须依赖链路追踪（如 OpenTelemetry）。事件可靠性要依赖消息队列的“至少一次投递”加消费者的幂等处理，事件乱序还要用版本号或状态机约束。

接力棒的弊端也明显：如果中途某棒手忘了传棒，你必须沿着整个赛道挨个询问“你收到消息了吗”。协同式 Saga 排查问题，就得靠完善的链路追踪，否则一次“事件丢失”可能让整个旅行悄无声息地停摆。

补偿事务设计

退订听起来简单，但处处是坑。你以为给酒店打了退款电话就万事大吉？可能酒店系统重复执行了两次退款；可能你的入住其实没订上（系统超时但没成功），退了个寂寞；还可能你退款刚打完，酒店又收到了旅行管家的“确认入住”消息——先退后订，顺序全乱了。

补偿事务设计有四个公认要点：反向操作、幂等设计、空补偿、悬挂处理。反向操作要求 C_i 是能真实抵消 T_i 副作用的新业务，比如“发货”的补偿是“拦截发货”，而不是“删除发货记录”——因为记录已经被下游系统消费了。

幂等设计是补偿的基石：消息可能重复投递、重试可能重复触发，补偿接口必须通过业务唯一键（如 refund_id）保证执行多次与执行一次结果相同。空补偿指 T_i 实际没提交成功时，补偿逻辑要能识别并跳过，避免“退了一个不存在的订单”。悬挂处理指补偿先于正向事务到达，需要用状态字段拦截后续的正向操作，防止“补完又订”。

好的退订系统就像酒店前台的“退订编号”：一个订单一个退订单号，重复打来电话就说“您已退订过了”。设计补偿事务时，脑子要时刻装着这个场景——重点不是“怎么退”，而是“怎么退都不会出错”。

并发控制策略

旅行中还有个经典冲突：你和另一位游客同时订同一班航班的最后一个座位。你们都在付钱，都以为订到了。更糟的是，你退票的同时，对方正在值机。没有并发控制，退订与入住就会互相踩踏。

Saga 不提供隔离性，多个 Saga 实例并发操作同一份数据时，可能产生脏读、脏写。常见策略有三类：乐观锁（版本号 + CAS）、悲观锁（分布式锁）、业务状态校验。乐观锁适合冲突少的场景：每次更新带上 version 条件，更新成功才继续；悲观锁（Redis/etcd 分布式锁）适合冲突激烈的场景，但要注意锁的持有时间与续期。

业务状态校验是最后一道防线，比如“只有当订单状态为 PAID 时才允许执行补偿”，从业务语义上拦截非法流转。三种手段可以叠加使用：状态校验兜底，乐观锁提高并发，悲观锁保护稀缺资源。

旅行社的“锁座”机制就是乐观锁的日常版：你选座时系统记下“该视图已被锁定，版本号 +1”，谁先提交谁成功。并发控制不是 Saga 的目标，但它是 Saga 能安全运行的护栏——没有护栏，再完美的退订流程也会被同时发生的另一场旅行撞得七零八落。

生产实践指南

成熟的旅行社不会只在旺季卖行程。它会预判台风季（超时预案）、给每个订单挂状态标签（监控大屏）、淡季时演练全套退票流程（故障演练）。Saga 要上生产，同样需要这些“非功能”功夫。

首先是适用场景：Saga 适合跨多个服务、流程较长、对实时一致性要求不高的业务，比如订单、预订、审批流。如果业务要求强一致（如账户余额实时扣减），Saga 并不合适，应考虑 TCC 或其他方案。

生产落地四件事：一，每个本地事务与补偿都设超时，超时按失败处理并触发重试；二，为补偿链路设置重试次数上限与退避策略，防止补偿风暴打垮下游；三，监控每个 Saga 实例的状态分布（执行中/失败/补偿中/终态），统计补偿成功率；四，定期做故障演练，人为注入服务故障，验证补偿链路能真正恢复。

每一次旅行都是对旅行社组织能力的考验。一个把退票流程演练过一百遍的管家，台风天依然从容。Saga 在生产环境的价值，不在它“设计得漂亮”，而在它“退得干净、看得清楚、扛得住故障”。

AI 应用场景

Python 演示

import randomimport time  class SagaOrchestrator:    """编排式 Saga：正向执行 + 逆向补偿"""     def __init__(self):        self.step_list = []      # 正向步骤: [(名称, 事务函数)]        self.comp_map = {}       # 步骤名 -> 补偿函数     def add_step(self, name, tx_func, comp_func):        self.step_list.append((name, tx_func))        self.comp_map[name] = comp_func     def run(self):        done = []        for name, tx_func in self.step_list:            try:                tx_func()                done.append(name)                print("[正向] {} 提交成功".format(name))            except Exception as exc:                print("[失败] {} 执行出错: {}".format(name, exc))                self._compensate(done)                return False        print("[完成] 所有事务提交成功")        return True     def _compensate(self, done):        for name in reversed(done):            comp_func = self.comp_map[name]            try:                comp_func()                print("[补偿] {} 已回退".format(name))            except Exception as exc:                print("[告警] {} 补偿失败: {}".format(name, exc))  def book_flight():    print("  订机票：北京→上海 已出票")  def cancel_flight():    print("  退机票：票款 1200 元原路退回")  def book_hotel():    print("  订酒店：外滩行政房 已确认")  def cancel_hotel():    print("  退酒店：房费 800 元原路退回")  def book_train():    raise RuntimeError("高铁余票不足")  def cancel_train():    print("  退高铁票：无出票记录，空补偿跳过")  def main():    saga = SagaOrchestrator()    saga.add_step("机票", book_flight, cancel_flight)    saga.add_step("酒店", book_hotel, cancel_hotel)    saga.add_step("高铁", book_train, cancel_train)    ok = saga.run()    print("最终一致性结果：", "行程全部确认" if ok else "行程已自动回滚")  if __name__ == "__main__":    main()

1. self.step_list = []保存正向步骤列表，self.comp_map = {} 保存每个步骤对应的补偿函数，两个集合属性与方法无同名冲突
2. def add_step(self, name, tx_func, comp_func)注册一个本地事务及其配套补偿，类似旅行管家往行程单里加一站
3. for name, tx_func in self.step_list:按注册顺序执行正向链路，对应 Saga 的 T1→T2→T3
4. except Exception as exc:捕获任一事务异常，立即跳出正向循环转入补偿，对应“Tk 失败则停止正向执行”
5. self._compensate(done)触发逆向补偿流程，对应公式中的 C(k-1)→……→C1
6. for name in reversed(done):按已提交列表的相反顺序逐一补偿，这是 Saga 逆向回退的核心
7. raise RuntimeError("高铁余票不足")模拟第 3 个本地事务失败，驱动演示进入补偿分支
8. ok = saga.run()执行整条 Saga 并返回是否全部成功，业务侧据此判断“全确认”还是“已回滚”

常见误区

面试题