1. Saga事务模型概述
1.1 Saga模式的定义
Saga是一种用于管理分布式系统中长活事务（Long-Lived Transaction）的架构模式。它将一个全局事务拆分为一系列本地事务（Local Transaction），每个本地事务都有对应的补偿事务（Compensating Transaction）。当某个本地事务失败时，Saga会按照逆序依次执行之前已成功事务的补偿操作，从而回滚整个业务流程。
核心思想：Saga通过“补偿”而非“回滚”来实现分布式一致性，避免了传统分布式事务中两阶段提交（2PC）的锁资源占用和协调者单点问题。
1.2 Saga与ACID事务的区别
传统ACID事务强调原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），适用于单体数据库内的短事务。Saga事务则针对分布式环境做了妥协，放弃了全局隔离性，通过补偿机制保证最终一致性。
| 对比维度 | ACID事务 | Saga事务 |
|---|---|---|
| 原子性 | 全有或全无，通过undo日志回滚 | 通过补偿事务逆向恢复，非即时回滚 |
| 一致性 | 强一致性，事务完成后数据立即一致 | 最终一致性，中间状态对外可见 |
| 隔离性 | 严格隔离（如可串行化、可重复读） | 无全局隔离，需应用层处理脏读 |
| 持久性 | 事务提交后数据永久保存 | 每个本地事务独立持久化 |
| 锁机制 | 持有锁直到事务结束，可能死锁 | 不持有跨服务锁，无死锁风险 |
| 适用场景 | 单体应用、短事务、高一致性要求 | 微服务、长活事务、高可用要求 |
关键差异：Saga事务不提供全局隔离性。在补偿执行期间，其他服务可能读取到中间状态数据（脏读）。设计时必须通过幂等性、补偿幂等和业务校验来规避数据不一致风险。
1.3 Saga在微服务中的价值
微服务架构中，每个服务拥有独立的数据库，传统分布式事务（如XA协议、2PC）面临以下挑战：
- 协调者单点：2PC协调者故障会导致所有参与者阻塞
- 锁资源竞争：长事务持有数据库锁，降低系统吞吐量
- 网络分区敏感：分布式环境下网络抖动导致事务悬挂
- 服务耦合：所有服务必须支持相同的协议接口
Saga模式通过以下方式解决上述问题：
1.4 Saga的两种实现模式
Saga事务有两种主流实现方式，各有适用场景：
| 特性 | 编排模式（Choreography） | 协调模式（Orchestration） |
|---|---|---|
| 控制方式 | 服务间通过事件驱动，无中心控制器 | 由协调器（Orchestrator）统一调度 |
| 服务耦合度 | 低，服务只关心自己订阅的事件 | 高，所有服务依赖协调器 |
| 复杂度 | 简单场景易于实现，复杂场景难追踪 | 适合复杂业务流程，便于监控和治理 |
| 补偿管理 | 每个服务自行发布补偿事件 | 协调器统一触发补偿流程 |
| 典型工具 | 消息队列（Kafka、RabbitMQ） | Camunda、Temporal、Seata |
选型建议：当业务流程少于5个服务且逻辑简单时，优先选择编排模式；当业务流程复杂、需要集中监控和超时管理时，推荐使用协调模式。本课程后续的故障排查案例均基于协调模式展开，因为超时和连接池水位问题在协调模式下更容易暴露和定位。