1. Saga模式概述
1.1 Saga模式的定义
Saga是一种用于管理分布式系统中长事务的异步补偿模式。它将一个全局事务拆分为多个本地事务（称为“步骤”），每个步骤都有对应的正向操作和补偿操作。当某个步骤失败时，Saga会依次执行之前已成功步骤的补偿操作，以回滚整个事务状态。
核心思想： 放弃传统ACID的强一致性，采用最终一致性 + 补偿机制，适用于跨服务、跨数据库的长事务场景。
1.2 Saga vs TCC vs 2PC 对比
三种分布式事务方案在一致性模型、资源锁定方式和适用场景上有本质区别：
| 对比维度 | Saga | TCC | 2PC |
|---|---|---|---|
| 一致性模型 | 最终一致性 | 最终一致性 | 强一致性 |
| 资源锁定 | 不锁定资源，释放快 | Try阶段预留资源 | 全局锁资源，阻塞 |
| 事务时长 | 支持长事务（分钟~小时） | 适合短事务（秒级） | 适合短事务（秒级） |
| 回滚机制 | 补偿操作（业务回滚） | Cancel操作（资源释放） | Rollback（资源回滚） |
| 隔离性 | 弱隔离（需业务补偿） | 中间隔离（Try阶段） | 强隔离（全局锁） |
| 典型实现 | 事件编排、状态机 | Try-Confirm-Cancel接口 | XA协议、Seata AT |
| 性能影响 | 低（无锁、异步） | 中（预留资源） | 高（同步阻塞） |
选型建议： 如果业务允许短暂不一致且事务执行时间长（如订单流程、审批流），优先选择Saga；如果要求强一致性且事务短（如扣库存），考虑2PC或TCC。
1.3 适用场景：长事务与跨服务
Saga模式特别适合以下两类场景：
- 长事务场景： 事务执行时间从几十秒到数小时不等，例如：
- 电商下单流程（创建订单 → 扣库存 → 支付 → 发货）
- 旅行预订（订机票 → 订酒店 → 租车）
- 审批工作流（提交申请 → 多级审批 → 执行）
- 跨服务场景： 事务涉及多个独立微服务，每个服务拥有自己的数据库，例如：
- 订单服务 + 库存服务 + 支付服务 + 物流服务
- 用户服务 + 积分服务 + 通知服务
1.4 Saga的两种协调模式
Saga的实现分为编排模式和状态机模式两种主流方式：
| 特性 | 编排模式（Choreography） | 状态机模式（State Machine） |
|---|---|---|
| 协调方式 | 服务间通过事件异步通信 | 中央协调器控制流程 |
| 耦合度 | 低（服务独立） | 中（依赖协调器） |
| 可观测性 | 弱（事件链追踪复杂） | 强（状态机日志清晰） |
| 典型实现 | Kafka/RabbitMQ事件驱动 | Seata Saga、Camunda |
| 压测关注点 | 消息队列吞吐、事件延迟 | 协调器并发、状态持久化 |
压测提示： 编排模式压测时需重点关注消息中间件的积压和消费延迟；状态机模式压测时需关注协调器的线程池耗尽和数据库状态写入瓶颈。