SAGA事务模式#

两种执行方式：

• 编排式：中心协调器控制步骤
• 事件式：每步完成发事件触发下一步

vs TCC： SAGA 不需要 Try 锁定资源，侵入性更低，但隔离性更差

SAGA模式是一种处理分布式长事务的方案，核心思路是将一个大事务拆分成多个本地事务按顺序执行，每个本地事务配一个补偿操作。正向流程是T1、T2、T3依次提交，如果中间某一步失败就逆序执行补偿操作C3、C2、C1来回滚之前已提交的操作。SAGA有两种编排方式：编排式由一个中心协调器统一控制每步的执行和补偿，流程可视化好但协调器是单点；事件式是每步完成后发事件触发下一步，去中心化但调用链追踪比较困难。和TCC对比，SAGA不需要Try阶段预留资源，对业务代码的侵入性更低，实现也更简单，但隔离性更差因为每步都是真正提交的中间状态对外可见。适用场景是跨多个微服务的长流程编排，比如旅行预订中订机票、订酒店、租车这种链式操作。需要注意补偿操作必须是幂等的，而且要考虑补偿操作本身失败的情况，通常需要重试机制加人工兜底。

追问方向：

• “SAGA 隔离性怎么保证？”→ SAGA 本身无隔离性（中间状态对外可见），可通过语义锁（状态字段标记处理中）、业务层读隔离（查询时过滤中间态）来缓解
• “编排式和事件式怎么选？”→ 编排式有中心协调器流程可视化好但存在单点，适合流程固定的场景；事件式去中心化解耦好但链路追踪难，适合服务独立演进的场景
• “补偿操作失败怎么办？”→ 补偿操作必须幂等 + 配置重试机制（指数退避），重试上限后告警人工介入，最终靠定时对账任务兜底发现未补偿的记录

易错点：

• ❌ SAGA 和 TCC 一样——SAGA 没有 Try 步骤
• ❌ 补偿一定能成功——需要重试和人工兜底