SAGA 是微服务架构中实现分布式事务的核心模式。它将一个全局事务拆分为多个本地事务，每个本地事务都有对应的补偿操作（Compensating Transaction）。当某个步骤失败时，SAGA 通过执行补偿操作来回滚已完成的步骤，从而保证系统的最终一致性。
在银行转账场景中，典型的 SAGA 流程：① 扣减转出账户余额 → ② 增加转入账户余额 → ③ 记录交易流水。如果步骤②失败，需补偿步骤①（恢复转出账户余额）。
SAGA最终一致性补偿事务SeataEventual Consistency| 测试场景 | 测试方法 | 预期结果 |
|---|---|---|
| 正常流程全成功 | 所有参与者均返回成功 | 事务提交，数据一致 |
| 中间步骤失败-补偿回滚 | 注入故障使第 N 步失败 | 前 N-1 步的补偿操作全部成功执行，数据回滚到初始状态 |
| 补偿操作失败-重试 | 补偿操作首次失败，后续重试成功 | 系统自动重试补偿操作，最终回滚成功 |
| 幂等性验证 | 同一事务消息重复投递 | 重复执行不产生重复扣款/重复入账 |
| 并发 SAGA 冲突 | 两个 SAGA 同时操作同一资源 | 通过乐观锁/悲观锁保证数据一致性 |
| 超时处理 | 参与者长时间无响应 | SAGA 超时后触发补偿，不允许事务悬挂 |
编排式 SAGA（Choreography）：各服务通过事件驱动方式协同，没有中央协调器。测试需验证事件发布顺序、事件丢失后的恢复机制、以及事件消费的幂等性。
协调式 SAGA（Orchestration）：SAGA 协调器统一管理事务流程。测试重点在于协调器的状态机转换是否正确、协调器崩溃重启后能否从断点恢复、以及补偿指令的发送是否可靠。
银行推荐：金融系统通常采用协调式 SAGA，因为集中式的状态管理更易于审计和排查问题。
| 工具/框架 | 用途 | 说明 |
|---|---|---|
| Seata | 分布式事务框架 | 阿里开源，支持 TCC、SAGA 等模式，提供全局事务管理 |
| Eventuate Tram | SAGA 编排框架 | 事件驱动的事务协调，支持消息可靠投递 |
| Testcontainers | 集成测试环境 | 为每个测试用例启动独立的数据库和消息队列容器 |
| Awaitility | 异步断言 | 等待最终一致性达成的断言工具 |
| Chaos Monkey | 故障注入 | 随机终止服务实例，验证 SAGA 容错能力 |