Saga 模式是我这几年做微服务改造时，被问到最多、也踩坑最多的一个分布式事务方案。它不像两阶段提交那样“一锁了之”，也不像 TCC 那样把业务代码塞得满满当当。很多同学刚接触它时觉得“不就一个补偿嘛”，真正上手才发现：补偿操作怎么设计、状态机怎么流转、隔离性怎么兜底，每个点都能让你线上出事故。这篇就按我自己的理解，把 Saga 从原理到落地、再到排障，完整捋一遍。
1. 为什么需要 Saga——分布式环境下的痛点
1.1 单体时代的一行代码，到了微服务就变成三张表
先回忆一个最经典的场景：用户下单。
单体应用里，一次订单事务无非是往订单表插一条记录、扣掉库存、锁住优惠券，三个操作包在同一个数据库事务里，要么全部成功，要么全部回滚。靠的是数据库的 ACID，一个BEGIN到COMMIT就完事，简单可靠。
但服务拆分之后，订单服务和库存服务各自持有独立的数据库。你没法再用一个BEGIN把它们包进同一个本地事务。客户端下单时，订单服务要先写订单数据，再远程调用库存服务扣库存。这时候如果订单写成功了、库存调用超时了，两边怎么办？回滚订单？那库存服务那边可能压根没执行。直接提交？用户会拿到一个“下单成功但没库存”的虚假订单。这种跨服务、跨数据库的数据一致性问题，就是分布式事务要解决的核心问题。
1.2 传统方案为什么会“失灵”
很多人第一反应是上两阶段提交（2PC）。这个方案在理论上是完备的，协调者先问所有参与者“能不能提交”，大家都说行，再统一提交。但在实际微服务场景里，2PC 的毛病非常明显：所有参与者要在第一阶段持有资源锁，等待协调者发出最终指令，这个等待时间一长，数据库连接池就容易被占满；协调者本身又是一个新的单点；更麻烦的是，很多微服务用的数据库、消息队列、缓存系统根本不支持 XA 协议。
TCC（Try-Confirm-Cancel）也常被拿来对比。TCC 的优点是隔离性控制得比较好，但它对业务的侵入性太强——每个服务都得把业务逻辑拆成 Try、Confirm、Cancel 三个方法，还要自己维护资源占用状态。在一个几十个微服务的系统里全面铺开 TCC，开发量是灾难性的。不少团队做了一半就放弃了，退回去用“本地消息表 + 定时任务对账”这种土办法。
Saga 模式正是在这种背景下被大规模采用的：它不强依赖数据库底层协议，不要求业务方把逻辑拆得支离破碎，核心思路就是“把一个大事务拆成一串本地事务，每一步都留好后手”。
1.3 Saga 的取舍：放弃隔离性，换取可用性
Saga 最本质的取舍是：它不保证隔离性，只保证最终一致性。这意味着在事务执行过程中，其他并发事务有可能读到中间状态的数据。比如在“下单 → 扣库存 → 发优惠券”这个 Saga 流程中，订单服务刚写完订单，库存还没扣完，这时候就有人查到“订单已支付”的记录，对业务来说这可能造成超卖或促销预算超发。
很多人一开始接受不了这一点，觉得“不保证隔离性那不是要出大事”。但换一个角度看：在一个高并发的电商系统里，为了极小概率的中间态可见问题，去承担 2PC 的资源锁开销，性价比很低。真实业务通常能通过“最终一致性 + 重试 + 对账”把风险兜住。所以你看到的大多数高性能微服务系统，最终选的都是 Saga 或者类似的异步补偿思路，而不是追求强一致。
一句话总结：Saga 适合“高可用优先、允许短暂不一致、业务可补偿”的场景；不适合账务类等绝对不能出现中间状态的系统。
2. Saga 的核心概念与设计思路
2.1 Saga 是什么：一组带“后悔药”的本地事务
Saga 的概念最早源于 1987 年的一篇论文，作者认为一个长生命周期的事务可以被拆分成一组“子事务”，每个子事务都是一个独立的本地事务，彼此之间通过事件或命令串联。如果中间某一步失败了，就反向执行之前各步骤的补偿操作。
我习惯用一个生活化的类比来理解：想象你规划了一次自驾游，路线是“家 → 加油站 → 景区 → 酒店”。如果到了酒店发现没房了，你不会把整趟行程全部抹掉（也不可能把车里的油倒回去），而是会“补偿”——重新订另一家酒店，或者直接开车回家。Saga 就是这个思路，每一步都在往前走，遇到走不通就回头把之前做的事逐步撤销或者替换。
正向操作和补偿操作之间存在一种对称关系：每一条正向操作都要有对应的补偿操作。比如“创建订单”的补偿是“取消订单”，“扣减库存”的补偿是“回补库存”，“冻结优惠券”的补偿是“释放优惠券”。设计阶段就要把这层对称关系画出来，缺一个都是隐患。
2.2 两种主流编排方式：事件编排与命令协调
Saga 的具体落地方式有两大流派，这也往往是团队里争论最多的地方。
事件编排（Choreography）。没有中心协调者，每个服务处理完自己的本地事务后，向消息队列发一个领域事件，下一个服务监听事件后继续执行自己的本地事务。比如订单服务发“订单已创建”，库存服务监听到就去扣库存，扣完发“库存已扣减”，优惠券服务监听到就去发券。链路上的每个节点都是对等的、解耦的，扩展性极好。缺点是流程散落在各个服务里，业务流转不直观，排查问题时得顺着事件链一路看，运维心智负担比较大。
命令协调（Orchestration）。引入一个专门的协调者服务（Saga 引擎），由它统一告诉各个参与方“现在该执行哪一步”。每个服务只暴露正向操作和补偿操作的接口，自己不关心整个流程的前后顺序。协调者内部通常用状态机来管理整个 Saga 的状态流转，出问题后由协调者统一发起补偿。这种方式流程集中、可观测性强、容易做人工干预，是当前业界的主流选择。
这两种方式没有绝对优劣，我用表格列出它们的关键差异：
| 对比项 | 事件编排 | 命令协调 |
|---|---|---|
| 中心依赖 | 无中心，靠消息队列串联 | 有中心协调者（Saga 引擎） |
| 服务耦合度 | 服务之间通过事件解耦 | 服务只需对接协调者 |
| 流程可观测性 | 弱，需查询事件链路 | 强，状态机一目了然 |
| 新增节点成本 | 低，发消息即可 | 中，需要扩展协调者逻辑 |
| 适合场景 | 链路简单、团队分工明确 | 链路复杂、需要严格管控 |
我个人观点是：链路在四个节点以内、团队对领域事件建模有信心，事件编排确实清爽；但一旦节点多了、补偿逻辑复杂了，命令协调的“集中可控”优势就完全压过事件编排。绝大部分生产项目，选命令协调不会错。
2.3 反向补偿的两种形式：后退恢复与向前恢复
补偿操作本身还分两种策略，经常被混为一谈。
后退恢复（Backward Recovery）。把已经执行成功的正向操作一个个撤销掉，恢复到初始状态。比如“取消订单”“回补库存”。这是大多数人对 Saga 补偿的第一反应，也是最直观的方式。
向前恢复（Forward Recovery）。不从失败点后退，而是继续往下执行，通过执行后续操作来绕过故障。举个例子：库存扣减失败后，不是把订单取消掉，而是改从另一个仓库发货，订单继续推进。
向前恢复在实际业务中其实很常见，但它需要业务规则支持“替代路径”。在 Saga 状态机设计时，我会为每个中间节点明确一个“失败策略”：优先尝试重试，重试数次仍失败，则判断是走补偿还是走替代逻辑。这一步想清楚，能减少很多无谓的“回滚”。
3. Saga 的实操落地——状态机设计与代码示例
3.1 状态机的四个核心要素
命令协调型 Saga 的落地关键就是状态机。我在项目里实现 Saga 引擎时，状态机需要维护四个核心字段：
- SagaId：代表一次完整事务的实例 ID，通常用 UUID，所有参与方都拿它作为关联 ID。
- 当前步骤：从 Starts 到 Done，记录执行到了哪个环节。
- 状态：Pending、Running、Success、Failed、Compensating、Compensated。
- 执行历史：记录每一步正向操作和补偿操作的结果，用于审计和重放。
状态机的流转规则我建议单独用一个枚举类定义，避免散落在业务代码里。下面是一个简化的 Java 风格定义：
public enum SagaState { PENDING, // 初始状态 RUNNING, // 正向流程执行中 SUCCESS, // 全部执行成功 FAILED, // 正向流程失败，准备补偿 COMPENSATING, // 补偿执行中 COMPENSATED; // 补偿完成 } public enum SagaEvent { STEP_SUCCEEDED, // 某一步正向执行成功 STEP_FAILED, // 某一步正向执行失败 COMPENSATED_STEP, // 某一步补偿执行成功 COMPENSATE_DONE; // 补偿全部完成 }状态机核心逻辑就是根据事件驱动状态迁移：正向执行成功就推进到下一步；失败就进入 COMPENSATING，反向逐一执行补偿操作；补偿全部完成后再落到终态 COMPENSATED。这个流转逻辑不要分散写在业务代码里，一定要收敛在统一的 Saga 引擎模块。
3.2 补偿操作必须遵守的三条原则
补偿方法不是随便写一个“反向接口”就行，我总结了三条必须遵守的原则：
可逆性。补偿操作必须能让业务数据回到“不违反业务规则”的状态，而不是字面意义的“原样”。比如支付的补偿是退款，而不是把支付记录删掉。删记录这种操作在金融审计场景里不可接受。
幂等性。补偿操作可能因为网络重试被执行多次，补偿方法必须天然幂等。最简单的手段是在业务表里增加一个compensated_flag字段，补偿前先判断标志位，已经补偿过的直接返回成功。
独立性。补偿操作不能依赖正向操作留下的线程上下文、事务上下文、内存缓存，因为补偿触发时这些上下文可能早已消失。补偿方法要做成“只依赖入参就能独立运行”的自治逻辑。
我第一次写补偿时犯过一个典型的错误：补偿方法里读取了应用内存里缓存的库存快照来“回补”库存。然而补偿发生在新实例上，缓存里根本没有这份数据，结果回补的金额变成了 null。后来改成从数据库读取原始订单和扣减流水，才彻底解决。
3.3 三类隔离性问题的解决思路
Saga 不保证隔离性，但业务上如果完全不处理，还是会出问题。业界总结了三种典型的“隔离性漏洞”，我在设计 Saga 时会针对性地做防护。
语义锁（Semantic Lock）。在 Saga 启动时，给关键资源打上一个“中间状态”标记，其他 Saga 看到这个标记就知道当前数据不可用，避免并发互相覆盖。比如“冻结库存”而不是直接“扣库存”，等 Saga 成功后真正扣减。这个思路本质上是把隔离性问题转换成“状态标记问题”，成本低、效果好。
可重读（ reread ）。Saga 执行过程中允许别人读到中间数据，但读到的数据必须携带状态信息，让下游知道当前数据可能变化。比如订单状态有“待确认”“已确认”两种，其他服务读取时根据状态决定是否信任。这种思路适合读多写少的场景。
上游读（ upstream read ）。针对“脏读”问题，强制要求下游服务在读数据时直接穿透到数据源头服务，而不依赖中间缓存或快照，确保读到的是当前最新状态。
3.4 一个完整的 Saga 流程示例
为了把上面这些落到具体的流程里，我画一个“下单送券”的 Saga 执行链路：
- 订单服务创建订单（状态为“待支付”）。
- 库存服务预占库存，返回预占结果。
- 支付服务执行支付扣款。
- 优惠券服务发放优惠券。
- 订单服务确认订单完成。
如果第四步发券失败，协调者开始反向补偿：
- 调用支付服务执行退款；
- 调用库存服务释放预占库存；
- 调用订单服务将订单标记为“已取消”。
注意这里每步的补偿操作都用同一个 SagaId 关联，消息队列的消息里也必须带上 SagaId，这样参与方才能做幂等判断，也方便出现问题后在日志里把整条链路的执行记录拉出来复盘。
如果第四步发券失败后，协调者发起补偿，但补偿过程中退款接口又超时了怎么办？我的经验是：补偿也要走状态机和重试机制，不要人为地“越级补偿”。补偿第一次失败后先重试，重试超过阈值再由待处理任务表接管，触发告警人工介入。
4. 常见问题与排查技巧实录——我在实战中踩过的坑
4.1 补偿操作顺序颠倒导致的数据错乱
我最早的一个 Saga 流程是“下单 → 扣库存 → 发券”，失败后补偿顺序我想当然地写成了“退券 → 回补库存 → 取消订单”。结果回补库存的接口先检查了订单状态，发现订单还在“支付完成”阶段，直接抛异常拒绝执行。问题原因就是补偿顺序必须严格和正向执行顺序相反，而且在设计状态机时就要把每个节点的前驱后继关系定义清楚，不能靠运行时临时组织。
后来我改成：状态机注册时，每个节点都显式声明compensatedBy指向自己的反向节点，协调者收集所有已成功的正向节点，再按注册顺序逆序执行补偿。这样代码的意图清楚，也方便单元测试校验补偿顺序。
4.2 幂等键设计漏掉“补偿”这条路径
做订单服务时，同一笔订单如果被补偿和正向流程同时触发，会导致状态被错误覆盖。举个例子：正向流程刚把订单状态改成“待发货”，补偿流程同时取消了订单，最后订单状态到底是待发货还是已取消？谁后执行谁覆盖，完全不可控。
解决方式是在业务侧维护一张唯一的saga_control表，以 SagaId 为唯一键，每一步操作执行前先INSERT IGNORE占位。能插入成功的才有权执行该步骤，插入失败的说明已有其他流程在处理。这样无论是正向操作、重复消息、补偿操作，都不会并发执行同一逻辑。
4.3 永不结束的 Saga：状态机卡死在中间态
Saga 状态机最常见的事故是：某个正向节点执行成功了，但因为消息丢失，协调者一直等不到结果，整个 Saga 卡在 RUNNING 状态。业务上表现为订单一直卡在“处理中”。排查起来最麻烦，因为服务本身没报错，所有接口看起来都正常。
我的排查套路是三步走：
- 查协调者状态表，找到长期处于 RUNNING 的 SagaId；
- 查消息队列的死信队列和重试队列，确认是哪条消息一直没被确认；
- 查该节点的执行日志，确认执行结果是否成功、落库是否提交。
针对这个问题，我会给 Saga 引擎加一个“超时扫描器”：一个定时任务每 30 秒扫一次状态表，把超时未完成的 Saga 重新踢进重试队列，并打一条告警。这个设计虽然简单，但在线上救回过不知道多少次卡死事故。
4.4 补偿失败后的最终底牌：待处理任务表
补偿操作本身也可能失败。所有重试都失败之后，如果还继续无脑重试，只会白白消耗系统资源。我最后的兜底手段是一张“待处理任务表”，Saga 引擎把补偿失败的步骤记录进去，由专用的对账服务定时捞取，结合人工介入完成最终处理。
这张表至少有这些字段：SagaId、事务类型、失败步骤、补偿参数快照、失败原因、重试次数、状态。补偿参数快照尤其重要，因为补偿执行时入参可能已经不可追溯。把补偿所需的参数在正向执行时就序列化存好，补偿流程就能独立于原始请求而存在，不会再受上下文丢失的困扰。
建议把“待处理任务表”和监控系统打通，补偿失败累计达到一定阈值就触发短信/电话告警，别让待处理任务变成无人问津的黑洞。
4.5 排查利器：事务日志一定要打全
做 Saga 排查时我感受最深的一点是：日志不全，什么事都查不了。我每次设计 Saga 引擎时，都会强制在每个参与方加日志，至少包含以下字段：
- SagaId 和步骤编号；
- 入参和出参的快照；
- 正向执行开始/完成/失败时间点；
- 补偿执行开始/完成/失败时间点；
- 触发补偿的具体原因和异常堆栈。
这套日志就像给每个 Saga 生成了一个“生命周期档案”。出现问题时，从日志里直接按 SagaId 搜索，就能把整个执行链路拼出来。真实排查中，我甚至遇到过某个参与方开发人员把 SagaId 写丢的情况，导致所有日志都查不到关联，纯靠时间范围去翻，效率极低。所以线上问题的前 10 分钟，往往都浪费在“判断日志字段是否完整”上。
5. 选型避坑建议与我的个人心得
5.1 什么时候别用 Saga
不是所有场景都适合 Saga。我在实践中总结出三类“别硬上 Saga”的情况。
第一类是真金白银的账务核心场景。涉及账户余额增减、积分资产变动等，如果用户发起支付后出现“资金已扣、积分没发、补偿又失败”的中间态，即使最终能对平，用户投诉和客诉处理也足够让团队焦头烂额。这类场景我建议老实使用 TCC 或其他强隔离方案，宁可代码复杂一点，也不要让中间态暴漏给用户。
第二类是补偿操作本身不可行的场景。例如发送短信、推送通知这类“一旦发出就收不回”的副作用操作，Saga 的补偿几乎无计可施。只能把这类操作放到 Saga 流程的末尾，作为最后一步“尽力而为”的执行，失败了靠对账去眼尾。
第三类是团队没有完善的监控告警体系的情况。因为 Saga 本身是最终一致，出现问题时通常不会立刻暴露，要靠日志、指标、告警才能及时发现问题。如果一个团队连基本的 trace 系统都没有，上线 Saga 就是在给自己挖坑。
5.2 轻量级状态机引擎还是完整框架
市面上现成的 Saga 框架有不少，也有基于通用状态机实现的方案。我的建议是：如果团队规模小、流程简单，完全可以用一个轻量级状态机引擎外加业务自己的持久化表来搭，反而比引入重量级框架更可控。重量级框架一般会提供消息重试、死信队列、监控面板，但代价是学习成本和运维成本。
我做的最小可用方案其实很朴素：一张saga_instance表存状态，一张saga_step_log表存执行流水，一个定时任务触发超时补偿，再加上业务侧自己实现的每一步接口。跑了大半年，稳定得很。只要状态机逻辑收口、幂等设计到位，Saga 的核心并不复杂，不要为了“架构感”引入过度设计。
5.3 最后再分享一个小技巧
Saga 的补偿触发条件不要只写“失败就补”。我见过不少事故，正向操作实际已经成功，但因为回调消息丢失，协调者判断失败去执行了补偿，结果把一笔本来成功的单子给“补偿”坏了。最稳妥的做法是：每个正向操作在设计时都额外提供一个“查询接口”，协调者收到失败信号后先调用查询接口确认真实状态，再决定是否补偿。“先确认，再补偿”这五个字，值得写进你们的 Saga 设计评审清单。
