分布式事务 / Saga 模式 004 — SAGA PATTERN

Saga 模式
长事务的
最终一致性解法。

在微服务架构下,跨服务的事务一致性是永恒的难题。传统 XA 分布式事务采用强一致性,存在性能差、阻塞时间长、无法适配长事务等短板。Saga 模式将一个全局长事务拆分为一系列独立本地事务,每个子事务配套补偿操作,失败时逆序执行补偿,最终达成数据一致。

一致性
最终
资源锁
无
实现模型
2MODES
补偿机制
逆序
CHAPTER 01
01/06

Saga 核心基础概念

理解 Saga 的三个基石:子事务、补偿操作、最终一致性。三者共同构成了"无全局锁、失败可回滚"的事务模型。

01 / LOCAL TX
子事务 Local Transaction
全局事务拆分后的每一步操作,仅在单个服务内执行,依靠本地数据库事务保证执行成功。
02 / COMPENSATION
补偿操作 Compensation
每个正向业务操作必须实现对应的回滚逻辑。业务操作必须可补偿,纯删除、无法撤销的业务场景不适合 Saga。
03 / CONSISTENCY
最终一致性
不存在全局锁,业务执行过程中数据短暂不一致;失败后通过补偿逐步修正,最终所有服务数据达成一致。
⚠ IMPORTANT PREREQUISITE 业务操作必须可补偿。纯删除、无法撤销的业务场景不适合 Saga——这是 Saga 模式能否落地的第一道判断门。
BUSINESS EXAMPLE
电商下单流程:正向 + 补偿

全局事务:创建订单 → 扣减库存 → 扣减账户余额。若执行到 T3 扣款失败,则逆序执行补偿:C3(无需执行)→ C2(恢复库存)→ C1(取消订单)。

SAGA FLOW — 正向执行 / 失败补偿
T1 → T2 → T3 ✕  ⟲  C2 → C1
T1 创建订单 ORDER SERVICE T2 扣减库存 STOCK SERVICE T3 扣除余额 ACCOUNT SERVICE FAILED T4 下一步 SKIPPED C3 无需执行 T3 FAILED · SKIP C2 恢复库存 COMPENSATE STOCK C1 取消订单 COMPENSATE ORDER
COMPENSATION LOGIC 补偿逆序执行:T3 失败 → C3 跳过(T3 本就未成功)→ C2 恢复库存 → C1 取消订单。每一步补偿都必须是幂等的,因为网络重试可能重复调用。
CHAPTER 02
02/06

两种实现模型 详解

协同式(Choreography)去中心化事件驱动,编排式(Orchestration)中心化调度控制。两种模式各有适用场景,选型决定了整个事务链路的维护成本。

2.1 / CHOREOGRAPHY
协同式 · 去中心化
事件驱动 · 无中央调度器
ORDER SERVICE PAYMENT SERVICE STOCK SERVICE INVENTORY SERVICE event event event event MESSAGE BROKER
✓ 架构去中心化,无单点调度中心
✓ 代码逻辑简单,不需要额外流程引擎
✕ 业务流程散落各服务,链路难梳理
✕ 流程复杂时事件爆炸,排查困难
SCENE流程简短、参与服务少的简单业务
2.2 / ORCHESTRATION
编排式 · 中心化调度
Orchestrator 主动控制 · 流程集中定义
SAGA ORCH. ORDER SERVICE PAYMENT SERVICE STOCK SERVICE INVENTORY SERVICE cmd cmd cmd cmd
✓ 全局事务流程统一维护,链路清晰
✓ 新增/修改流程只调整调度器,不改微服务
✕ 调度器存在单点风险,需保证高可用
✕ 需额外引入流程引擎(Seata、Camunda)
SCENE复杂长事务、跨多服务、频繁变更的核心业务
COMPARISON TABLE
两种模式横向对比
维度 协同式 Saga 编排式 Saga
调度中心 无中心,消息驱动 中心调度器主动控制
流程定义 分散在各个服务 集中保存在调度器
维护成本 简单流程友好,复杂流程难以维护 复杂业务易于维护、可视化
技术依赖 可靠消息队列 流程调度引擎
单点风险 无 调度器需要集群保障高可用
CHAPTER 03
03/06

Saga 与其他 分布式事务方案对比

XA、TCC、Saga 三种主流方案的横向对比。每种方案都有其适用边界,选型本质是在性能、一致性、开发成本三角中做取舍。

01 / XA · 2PC
XA 模式
两阶段提交 · 强一致性
一致性
强一致性
性能
差,资源长期锁定
侵入性
低,依赖数据库层
场景
短事务、传统单体拆分简单场景(尽量避免)
02 / TCC
TCC 模式
Try-Confirm-Cancel · 三段式
一致性
高可靠,隔离中间状态
性能
较好,无长期锁
侵入性
极强,每接口开发三套逻辑
场景
资金交易等高严谨场景
03 / SAGA
Saga 模式
本地事务 + 补偿 · 最终一致性
一致性
最终一致,中间状态可见
性能
高,无资源锁
侵入性
中,正向 + 补偿两套接口
场景
长事务、跨多服务的核心业务流程
💡 SELECTION EXPERIENCE 追求高性能长事务、业务支持补偿操作 → Saga
资金交易等高严谨场景,需要隔离中间状态 → TCC
短事务、传统单体拆分简单场景 → XA(尽量避免)
CHAPTER 04
04/06

工程落地 核心痛点与解决方案

四类高频工程痛点,每一类都对应过真实的线上故障。Saga 不是银弹,落地前必须想清楚这些边界问题。

01
补偿操作幂等性
PAIN POINT 网络重试可能重复调用补偿接口,导致补偿逻辑被执行多次,数据被过度回滚。 SOLUTION 所有正向、补偿接口强制实现幂等,使用全局 Saga 事务 ID 作为幂等标识,重复请求直接返回成功。
02
补偿操作执行失败(悬挂问题)
PAIN POINT 补偿调用超时、服务宕机,导致回滚不完整,部分服务数据已变更但未补偿。 SOLUTION 调度器持久化事务状态,后台定时任务持续重试补偿,设置最大重试次数,超过后人工兜底告警。
03
脏读问题
PAIN POINT Saga 无隔离机制,事务执行中途,外部请求可以读到未提交的中间数据,业务决策可能基于不一致的状态。 SOLUTION 业务层增加状态控制(例如订单"处理中"状态禁止操作),或业务层面接受短暂不一致,前端展示"处理中"语义。
04
空补偿、防悬挂
PAIN POINT 空补偿:正向操作未执行成功,补偿逻辑被触发;防悬挂:补偿请求先于正向请求到达。 SOLUTION 每个服务本地记录 Saga 事务执行状态,根据状态判断是否允许执行补偿——无对应正向记录则拒绝补偿,已有补偿记录则拒绝正向。
STATE MACHINE
空补偿与防悬挂的状态判断
saga_state_guard — 防悬挂 + 防空补偿
// 每个服务本地维护 saga 事务状态表
// saga_id | forward_status | compensate_status

→ 正向操作执行前:
  if compensate_status == DONE:
    REJECT // 防悬挂:补偿已执行,正向不可再来
  else if forward_status == DONE:
    SKIP // 幂等:正向已执行
  else:
    execute forward & set forward_status = DONE

→ 补偿操作执行前:
  if forward_status != DONE:
    SKIP // 空补偿:正向未执行,补偿无意义
  else if compensate_status == DONE:
    SKIP // 幂等:补偿已执行
  else:
    execute compensate & set compensate_status = DONE
CHAPTER 05
05/06

主流 开源框架实现

三个生产级可用的 Saga 框架,分别对应不同的生态与场景。选型时除功能外,还需考虑团队技术栈与社区活跃度。

01 / SEATA
Seata Saga
Alibaba · Java · 编排式
国内最常用的分布式事务框架,支持编排式 Saga,支持 JSON 定义事务流程,兼容 Java 微服务生态。与 Spring Cloud、Dubbo 深度集成,社区活跃。
02 / SERVICECOMB
Apache ServiceComb Saga
Apache · 双模式
成熟的 Saga 事务框架,去中心化协同 + 编排模式双支持。华为开源贡献,现已入 Apache 孵化,适合多语言混合架构。
03 / CAMUNDA
Camunda / Zeebe
Workflow Engine · 通用
通用工作流引擎,可作为 Saga 调度器使用,适合复杂业务流程。提供可视化流程设计器,支持 BPMN 2.0 标准,便于业务方参与流程定义。
SUMMARY
06/06

总结 本地事务 + 补偿机制

Saga 模式是微服务长事务场景下首选的最终一致性方案,依靠"本地事务 + 补偿机制"规避 XA 锁竞争性能瓶颈。

01
短流程、少服务场景:选用协同式 Saga,事件驱动、去中心化、实现简单。
02
核心复杂业务、长履约流程:优先编排式 Saga,借助调度引擎统一管控事务状态。
03
清醒认知:Saga 无法实现强一致性,业务设计必须容忍短暂数据不一致。
04
所有业务接口必须支持补偿回滚,并实现幂等——这是 Saga 落地的前置条件。
结语 / EPILOGUE

Saga 不是银弹,
是 工程取舍 的产物。

分布式事务没有完美解。XA 牺牲性能换强一致,TCC 牺牲开发效率换隔离性,Saga 牺牲中间状态可见性换长事务的可行性。每一种方案都是在性能、一致性、开发成本三角中做取舍。

Saga 的核心价值在于:它让跨服务的长流程业务不再被全局锁束缚,通过"本地事务 + 补偿"的组合,把强一致性问题降维成最终一致性问题。这是电商订单、履约、供应链这类长链路业务能在微服务下跑起来的根本前提。

但请记住:选择 Saga,就意味着接受短暂不一致、承担补偿逻辑的开发成本、处理空补偿与悬挂问题。工程没有银弹,只有合适的取舍。