Saga 事务模式

Saga 事务模式是一种管理长时间运行事务(long-lived transaction)的方法,由普林斯顿大学的埃克托·加西亚-莫利纳(Hector Garcia-Molina)与肯尼思·塞勒姆(Kenneth Salem)在 1987 年的论文《Sagas》中提出,如今是微服务架构下分布式事务的主流方案之一。

概述

传统 ACID 事务要求持锁直到提交,若一个业务流程横跨多个服务、耗时数秒甚至数天(如订机票加订酒店加扣款),全程加锁代价不可接受。Saga 的思路是:把整个流程拆成一系列各自独立提交的本地事务 T1、T2……Tn,并为每一步预先定义补偿事务 C1、C2……;若第 k 步失败,则按 C(k-1)、C(k-2) 直至 C1 的顺序逆向补偿,把系统恢复到语义上等价于未执行的状态。它放弃了隔离性,提供的是最终一致性。

核心原理

• 本地事务链:每一步只在本服务的数据库内提交,立即释放锁,不存在全局锁与全局协调者阻塞。
• 补偿而非回滚:已提交的步骤无法数据库级回滚,只能用业务层的反向操作(如退款、释放库存)抵消。
• 两种协调方式:编排式(orchestration)由一个中央协调器依次调用各步并决定补偿;协同式(choreography)由各服务监听事件自行触发下一步,无中心节点。
• 可靠消息:步骤间通常借助消息队列与本地消息表(Outbox)保证指令不丢失,并要求各步骤幂等以容忍重试。

应用场景

电商下单(创建订单、扣库存、扣款、发货)、旅行预订、金融转账流程等跨服务业务广泛使用 Saga。开源实现包括 Apache 孵化的 ServiceComb Saga、阿里的 Seata(其 Saga 模式)、Axon、Temporal 等工作流引擎。

常见问题

问:Saga 与 TCC 有什么区别？答:TCC 要求每个服务实现试探(Try)、确认(Confirm)、取消(Cancel)三个接口,先预留资源再确认,隔离性更好;Saga 每步直接提交、失败再补偿,侵入更小但中间状态对外可见。

问:补偿失败了怎么办？答:通常持续重试(要求补偿幂等),仍失败则记录并转人工处理;设计时应尽量把最容易失败的步骤放在链条前部。

问:Saga 保证隔离性吗？答:不保证。其他请求可能读到中间状态,需用语义锁、状态标记或业务规则(如订单处理中状态)来缓解脏读问题。