结论：Saga 把一个分布式事务拆成一串本地事务，每个本地事务有对应的补偿操作，任何一步失败就按逆序执行已完成步骤的补偿，用最终一致性替代强一致的 2PC。

展开：以「下单 → 扣库存 → 扣款」为例，若扣款失败，则执行「回补库存 → 取消订单」两个补偿事务。两种编排方式：1）编排式（Choreography）：各服务通过事件驱动，各自监听并触发下一步，服务间解耦但流程分散难追踪；2）编制式（Orchestration）：引入 Saga 协调器统一调度各步骤，流程可视化、易维护，代价是协调器是逻辑中心。落地框架有 Seata（Saga/TCC 模式）、Temporal、Camel。必须面对的三个坑：1）补偿不等于回滚——已提交的本地事务无法物理回滚，补偿是业务层反向操作，要求每步都设计好幂等的补偿接口；2）隔离性缺失——中间状态对其他事务可见（脏读），订单「处理中」状态、库存预扣（TCC 思路）都是缓解手段；3）重试与幂等——协调器崩溃恢复后会重放，所有参与者接口必须幂等。与 TCC 对比：TCC 的 Try 阶段做资源预留，隔离性更好但对业务侵入大、开发成本高；Saga 侵入小，适合长事务和跨老系统场景。