📚 课程目录第1章 Saga事务基础

Saga事务补偿机制在压测场景测试与案例实战中的调优 - 第1节

1.1 Saga 模式定义

Saga 是一种用于管理分布式系统中长事务的架构模式。它将一个全局事务拆分为一组有序的本地子事务，每个子事务都是一个独立的 ACID 事务。Saga 的核心思想是：如果某个子事务失败，则通过执行之前已成功子事务的补偿操作来撤销其影响，从而保证最终一致性。

  关键特征： Saga 没有全局锁，不依赖两阶段提交（2PC），通过异步消息或事件驱动协调，适用于跨服务、跨数据库的分布式场景。

1.2 Saga 与 ACID 对比

传统 ACID 事务强调原子性、一致性、隔离性和持久性，通常依赖数据库锁和本地事务管理器。Saga 则牺牲了隔离性（允许中间状态可见），以换取更高的可用性和吞吐量。下表从多个维度对比两者差异：

维度	ACID 事务	Saga 事务
原子性	全有或全无，通过回滚实现	通过补偿操作实现最终原子性
一致性	强一致性，事务结束后立即一致	最终一致性，允许短暂不一致窗口
隔离性	严格隔离（如可串行化）	无隔离或弱隔离（需应用层处理）
持久性	依赖数据库 WAL 日志	依赖消息队列或事件存储
锁机制	数据库行锁/表锁	无全局锁，仅本地事务锁
适用场景	单体应用、短事务、低并发	微服务、长事务、高并发
典型实现	数据库本地事务、XA 协议	编排 Saga、协同 Saga

选型建议： 如果业务对强一致性有硬性要求（如金融转账），优先考虑 ACID；如果追求高可用和弹性伸缩，且能接受短暂不一致，Saga 是更优选择。

1.3 Saga 适用场景

Saga 并非万能，它最适合以下三类场景：

跨微服务的长事务： 例如电商下单流程（订单、库存、支付、物流），每个服务独立部署，无法使用本地事务。
高并发写入场景： 如秒杀系统，2PC 的阻塞锁会严重降低吞吐量，Saga 的无锁设计更适合。
异步最终一致性业务： 如用户注册送积分、内容审核后更新状态，允许短暂延迟。

不适用场景： 需要实时强一致性（如银行核心账务）、子事务间存在复杂数据依赖、补偿操作不可逆或成本极高（如发送邮件后无法撤回）。

1.4 Saga 核心概念

1.4.1 补偿（Compensation）

补偿是 Saga 的基石。每个子事务 T_i 都必须对应一个补偿事务 C_i，用于撤销 T_i 已产生的副作用。补偿操作必须是幂等的，因为网络故障或重试可能导致补偿被多次执行。

// 示例：订单服务的补偿逻辑
public class OrderService {
    @Transactional
    public void createOrder(Order order) {
        // 正向操作：创建订单，状态为“待支付”
        orderRepository.save(order);
    }

    @Transactional
    public void compensateCreateOrder(String orderId) {
        // 补偿操作：将订单状态改为“已取消”
        orderRepository.updateStatus(orderId, "CANCELLED");
    }
}

1.4.2 编排（Choreography）

编排模式中，每个服务在完成本地事务后，通过事件总线发布消息，触发下一个服务的执行。没有中央协调器，服务之间通过事件链耦合。

1.4.3 协同（Orchestration）

协同模式引入一个中央协调器（Orchestrator），负责向各服务发送指令，并处理成功/失败后的补偿逻辑。协调器通常以状态机形式实现，便于追踪和恢复。

1.4.4 编排 vs 协同：选型对比

维度	编排模式	协同模式
协调方式	事件驱动，无中心	中央协调器
耦合度	服务间通过事件耦合	服务与协调器耦合
复杂度	低，适合简单链路	中高，适合复杂分支
可观测性	弱，事件流分散	强，协调器集中记录
补偿管理	每个服务自行发布补偿事件	协调器统一触发补偿
典型实现	Kafka + 服务监听	状态机框架（如 Axon、Camunda）

压测视角： 编排模式在压测中更容易出现事件堆积和补偿风暴，需要关注消息队列的积压指标；协同模式则需重点监控协调器的状态机吞吐量和补偿重试次数。