分布式事务压测工程中Saga事务补偿数据传输优化 - 第1节
1.1 分布式事务背景：从单体到微服务的挑战
在单体应用架构中，所有业务逻辑共享一个本地数据库，事务由数据库自身的 ACID 特性保证。随着业务规模增长，系统向微服务架构演进，每个服务拥有独立的数据库实例，原本在一个本地事务中完成的跨库操作，现在需要跨越多个服务、多个数据库，甚至多种异构数据源。此时，传统的本地事务无法跨服务边界生效，分布式事务成为必须解决的核心问题。
核心矛盾：微服务架构追求独立部署与独立数据存储，但业务一致性要求跨服务操作要么全部成功，要么全部回滚。分布式事务正是在“服务自治”与“全局一致”之间寻找平衡的技术方案。
分布式事务面临的主要挑战包括：
- 网络不确定性：服务间调用可能超时、重试或丢失，导致状态不一致。
- 数据异构性：不同服务可能使用 MySQL、Redis、MongoDB 等不同存储，无法依赖单一数据库的锁机制。
- 性能损耗：强一致性协议（如 2PC）需要全局锁和协调者，在高并发场景下吞吐量急剧下降。
- 调试与追踪困难：跨服务的事务链路长，出现异常时难以定位是哪个环节失败。
业界为解决这些问题，提出了多种分布式事务模型，其中 Saga 模式因其对长事务和高并发场景的良好支持，成为微服务架构中最流行的方案之一。
1.2 Saga 模式定义：补偿而非回滚
Saga 模式最早由 Hector Garcia-Molina 和 Kenneth Salem 在 1987 年提出，其核心思想是：将一个长事务拆分为一系列有顺序的本地子事务，每个子事务对应一个补偿操作（Compensation）。当某个子事务失败时，Saga 按照相反顺序依次调用之前已成功子事务的补偿操作，以撤销其影响。
与传统的“回滚”（Rollback）不同，Saga 的补偿是业务层面的逆向操作，而非数据库层面的数据恢复。例如，一个“创建订单”操作的补偿是“取消订单”，而不是将订单记录从数据库中物理删除。
关键区别：回滚是技术层面的数据还原，补偿是业务层面的逆向操作。补偿操作必须是幂等的，以应对重试场景。
Saga 有两种常见的编排方式：
| 编排方式 | 核心机制 | 优点 | 缺点 |
|---|---|---|---|
| Choreography（ choreography） | 每个服务在完成本地事务后，通过事件总线发布消息，触发下一个服务的操作。没有中央协调者。 | 架构轻量，服务间解耦，适合简单流程。 | 流程隐式，难以监控和调试；循环依赖时容易死锁。 |
| Orchestration（编排） | 引入一个中央协调者（Orchestrator），负责向各个服务发送指令，并跟踪每个步骤的状态。 | 流程显式，易于管理、监控和重试；适合复杂流程。 | 协调者可能成为单点瓶颈，增加架构复杂度。 |
以下 SVG 展示了 Saga 编排模式的基本流程：
1.3 Saga 与 TCC / XA 对比
为了更清晰地理解 Saga 的定位，下表从多个维度对比了三种主流分布式事务方案：
| 对比维度 | Saga | TCC（Try-Confirm-Cancel） | XA（2PC） |
|---|---|---|---|
| 一致性模型 | 最终一致性 | 最终一致性 | 强一致性 |
| 资源锁定 | 不锁定资源，事务间无阻塞 | Try 阶段预留资源，Confirm/Cancel 释放 | Prepare 阶段锁定资源，Commit/Rollback 释放 |
| 事务时长 | 支持长事务，无时间限制 | 支持中长事务，Try 阶段不宜过长 | 短事务，锁定时间敏感 |
| 隔离性 | 弱隔离（需业务层处理脏读） | 通过预留资源提供一定隔离 | 强隔离（可序列化） |
| 性能 | 高（无锁、异步） | 中（Try 阶段有资源预留开销） | 低（同步阻塞、锁竞争） |
| 实现复杂度 | 中（需定义补偿逻辑） | 高（需定义 Try/Confirm/Cancel 三个接口） | 低（数据库原生支持） |
| 典型场景 | 订单流程、跨行转账、旅游预订 | 库存扣减、账户扣款 | 金融核心交易、对一致性要求极高的场景 |
选型建议：如果业务允许短暂的不一致窗口（秒级到分钟级），且追求高吞吐和长事务支持，优先选择 Saga。如果要求强一致性且事务短平快，XA 仍是可靠选择。TCC 则介于两者之间，适合需要预留资源的场景。
1.4 Saga 适用场景
Saga 模式并非万能，它在以下场景中表现尤为突出：
- 跨服务长事务：例如电商下单流程（扣库存 → 创建订单 → 支付 → 发货），每个步骤可能耗时数秒甚至更久，使用 Saga 可以避免长时间锁定资源。
- 高并发读写混合场景：Saga 不持有数据库锁，允许其他事务并发读写同一数据，适合秒杀、抢购等场景。
- 异构数据源：当服务使用不同类型的数据库（如 MySQL + Redis + MongoDB）时，Saga 通过业务补偿实现一致性，不依赖底层数据库的分布式事务协议。
- 业务流程可逆：每个操作都有明确的业务逆向操作（如“退款”对应“支付”），这是实现补偿的前提。
以下 SVG 展示了 Saga 在典型电商下单流程中的应用：