3. Saga模式基础
3.1 Saga模式的定义与起源
Saga模式是一种用于管理分布式系统中长时间运行事务的架构模式。它将一个全局事务拆分为一系列本地事务，每个本地事务都有对应的补偿操作，用于在失败时回滚已提交的更改。Saga模式的核心思想是：放弃ACID的原子性与隔离性，转而通过补偿机制保证最终一致性。
起源背景：1987年，Hector Garcia-Molina和Kenneth Salem在论文《Sagas》中首次提出该模式，用于解决长事务（Long-Lived Transaction, LLT）在传统数据库中的资源锁定问题。在微服务架构兴起后，Saga模式被重新发现并广泛应用于跨服务的数据一致性场景。
Saga模式的两个核心概念：
- 本地事务（Local Transaction）：每个服务内部执行的原子操作，提交后立即释放资源。
- 补偿事务（Compensating Transaction）：当某个本地事务失败时，反向执行已成功事务的补偿操作，撤销其影响。
3.2 Saga与2PC的对比
两阶段提交（2PC）是传统分布式事务的经典方案，而Saga模式代表了另一种设计哲学。两者在一致性模型、资源锁定、性能表现等方面存在本质差异。
| 对比维度 | 2PC（两阶段提交） | Saga模式 |
|---|---|---|
| 一致性模型 | 强一致性（ACID） | 最终一致性（BASE） |
| 资源锁定 | 事务期间持有锁，阻塞其他访问 | 每个本地事务提交即释放锁，无阻塞 |
| 事务协调者 | 需要全局协调者（Coordinator） | 无中心协调者，通过编排或 choreography 驱动 |
| 失败处理 | 回滚所有参与者（原子回滚） | 执行补偿事务（语义回滚） |
| 隔离性 | 支持隔离性（通过锁实现） | 弱隔离性，需应用层处理脏读 |
| 性能 | 低（锁等待 + 网络往返多） | 高（无锁、异步化） |
| 适用场景 | 短事务、低并发、强一致性要求 | 长事务、高并发、跨微服务 |
| 典型实现 | XA协议、Seata AT模式 | 事件驱动、消息队列、状态机 |
关键决策点：2PC适用于数据库层面、短时间内的强一致场景（如银行转账）；Saga适用于微服务间、长时间跨度的最终一致场景（如电商下单流程）。选择错误会导致性能灾难或数据不一致。
3.3 Saga的适用场景与优势
Saga模式并非万能，它在特定场景下才能发挥最大价值。以下是最适合采用Saga模式的典型场景：
- 跨微服务的长事务：订单创建涉及订单服务、库存服务、支付服务、物流服务，每个服务独立部署，无法使用本地事务。
- 高并发与低延迟要求：2PC的锁机制在高并发下成为瓶颈，Saga的异步补偿机制更适合互联网高流量场景。
- 业务流程可补偿：业务操作本身具有可逆性（如取消订单、退款、回滚库存），而非不可逆操作（如发送短信、打印凭证）。
- 事件驱动架构：团队已采用消息队列（Kafka、RabbitMQ）或事件流平台，天然适合Saga的Choreography模式。
Saga模式的核心优势可以归纳为以下四点：
| 优势 | 说明 | 业务价值 |
|---|---|---|
| 高可用性 | 无全局锁，服务可独立伸缩；单个服务故障不影响其他服务 | 系统整体可用性提升，故障隔离 |
| 高性能 | 本地事务提交后立即释放资源，无阻塞等待 | 吞吐量高，响应时间低 |
| 异步解耦 | 通过事件或消息驱动，服务间松耦合 | 易于扩展和维护，支持异构技术栈 |
| 业务语义清晰 | 补偿操作直接对应业务回滚（如退款、取消订单） | 业务逻辑可理解、可审计 |
实践建议：在采用Saga模式前，务必与业务方确认操作的可补偿性。例如“发送欢迎邮件”是不可补偿的（无法撤回已发送的邮件），而“扣减库存”是可补偿的（回滚库存数量）。对于不可补偿操作，应将其放在Saga流程的最后执行，或使用“预留-确认”模式（如TCC）处理。