SAGA事务

什么是SAGA事务

SAGA 的意思是“长篇故事、长篇记叙、一长串事件”。SAGA 事务模式的提出非常早，甚至早于分布式事务概念的提出。

SAGA 于 1987 年由普林斯顿大学的 Hector Garcia-Molina 和 Kenneth Salem 在 ACM 发表的论文《SAGAS》中提出。

这篇论文讲述的核心是如何处理长时间活跃的事务，SAGA 指出可将其拆分成可以交错运行的子事务集合，每个子事务都是一个真实的事务，子事务可以独自保证数据一致性。

为什么需要SAGA

之前我们介绍了 TCC 分布式事务解决方案，它拥有诸多优点：更强的一致性、更强的个理性、更好的性能，但是他也有一个显著的缺点就是业务侵入性强。业务侵入性强并不只是说我们编码麻烦而已，有时候业务不是你想侵入就侵入的，比如其他部门不愿意配合，比如使用三方系统。

依旧是以我们熟悉的电商业务为例子，需要经过下单、余额支付、库存扣件这三个过程，之前我们已经用TCC实现了这个过程。假设现在新增一个业务场景，余额支付需要替换为直接使用绑定的银行卡付款，现在又怎么做？银行并不像是我们的自有系统一样，可以提供专门的接口供我们去将本次事务所需的资源占用、资源提交、以及资源回滚。

如果不能用TCC，怎么办？这种情况下，SAGA 就有了用武之地。

SAGA 内容

SAGA 基本协议内容如下：

• 每个 SAGA 事务都由一系列的有序子事务(sub-transaction) T1，T2，…，Ti，…，Tn组成，每个事务都支持幂等。
• 每个 Ti 都有对应的补偿动作Ci，比如 C1，C2，…，Ci，…，Cn，补偿动作用于撤销 T1，T2，…，Ti，…，Tn造成的影响。同样，补偿操作也需要支持幂等。

如果 T1 到 Tn 均成功提交，那么事务就顺利完成。只有有一个环节出现失败就要采取恢复策略。

恢复策略分为向前恢复和向后恢复两种，具体使用那种方案需要根据实际场景选择。

向前恢复（Forward Recovery）

如果某个环节的Ti事务提交失败，那么就对这个 Ti 事务不断进行重试（接口要幂等），直到接口返回成功。

正向恢复不需要对应的补偿动作Ci，适用于在业务上都为正向操作的场景。继续以电商为例，如果用户的订单付款成功，那就一定要发货。

顺序为 T1、T2、T3 （失败，不断尝试，继续执行）、T4……

如下图：

向后恢复（Backward Recovery）

如果某个环节的Ti事务提交失败，那么就执行这个 Ti 事务对应的补偿Ci操作，不断进行重试（Ci接口要幂等），直到接口返回成功。

这里要求 Ci 必须可以执行成功，适用于在业务上允许失败的场景。继续以电商为例，如果用户的订单支付失败，那么需要支付、订单和库存都执行补偿。

顺序为 T1、T2、T3（失败）、C3、C2、C1

如下图：

实现SAGA

实现SAGA注意事项

如果实现SAGA，有三个需要注意的点：

1. Ti和Ci是幂等的，因为都需要重试以保证最终一致性。
2. Ci 必须是能够成功的，否则SAGA将无法撤销影响，如果无法成功则需要人工介入做补偿。
3. Ti 和Ci的执行顺序可以交换，不保证Ti一定在Ci前执行，但是最终执行效果相同，即子事务Ti影响被撤销。

这里着重说一下第三点，为什么要求Ci可以在Ti之前执行？因为网络之间的不稳定性，无法保证Ti一定执行，或者一定在Ci之前执行。具体来说，有以下三种执行情况。

1. 正常情况：Ti先执行，Ci后执行。
2. Ti请求因为网络问题丢失了，彻底不会执行。
3. Ti执行超时，判断为执行失败，直到Ci执行前 Ti 都没有执行完成，导致出现Ci先执行的情况。

所以，有了第三点的要求，Ti 和 Ci 顺序可交换。

两种模式

通过阅读SAGA协议的具体内容，我们可以发现，实现的关键之一子事务之间的协调。首先我们要知道一个事务的开始，并且可以让子事务按顺序执行，并且在某个事务执行完后通知下一个子事务。如果有子事务执行失败，需要按照顺序执行补偿逻辑。

所以根据协调子事务的方法，可以分为两类：命令协调模式和事件编排模式。

• 编排（Choreography）：
• 控制（Orchestration）：

命令协调模式（Orchestration）

命令协调模式：由中央协调器集中处理事件的决策和业务逻辑排序，以命令或者回复的方式与每个参与服务进行通信，全权负责告诉每个参与者什么时候该做什么。

依旧以之前的电商为例：

1. 事务发起者调用SAGA控制器开启事务（这里的控制器也可以由发起者兼任）。
2. SAGA中央协调器发起扣减库存，库存扣减结果返回。
3. SAGA中央协调器发起创建订单，订单创建结果返回。
4. SAGA中央协调器发起支付请求，支付结果返回。
5. SAGA中央协调器处理最终结果，并返回给应用程序。

SAGA中央协调器预先知道完整的事务处理流程，这可以通过配置实现。如果任意子事务失败失败，它便向每个参与者发送命令来执行补偿操作Ci（或者执行重试-向前恢复）。

其缺点很明显，既然有中央协调器就会有单点问题。

但是优点也很多，主要有：服务之间的编排顺序明确，依赖关系简单，不会有循环依赖；耦合相对较少，参与者只需要依赖协调者接口，参与者之间没有直接依赖；参与者只需要关注自身业务，服务之间协调统一由协调器管理。

事件编排模式

事件编排模式：SAGA 中的参与者通过交换事件进行沟通，按照提前编排好的发布顺序决策和排序。

这种模式没有单点风险，由每个服务监听对应事件，并对事件做出反应。SAGA事务由应用程序发布第一个事件开始，中间服务接受到对应事件做本地事务的处理，然后继续发布事件。每一个事件由一个或者多个服务监听。当最后一个服务执行本地事务并发布事件后，Application 收到最后一个事件，事务结束，事件处理的顺序都是提前编排好的。具体参考下图：

电商订单的例子为例：

1. 应用程序发起SAGA事务，以订单事件发布开始。
2. 库存服务监听开始订单事件，扣减库存，成功后发布库存扣减事件。
3. 订单服务监听库存扣减事件，创建订单，并发布订单已创建事件。
4. 支付服务监听订单创建事件，进行支付，并发布订单已支付事件。
5. 应用程序监听支付成功事件，SAGA事务结束。

事件/编排是实现 SAGA 模式的自然方式，它通过事件串联各个服务，实现了服务之间的松耦合。并且实现简单，只需要在执行本地事务时发布事件。如果事务涉及 2 至 4 个步骤，则可能是非常合适的。

但是有一些缺点：因为代码中没有明显的编排逻辑，所以可能会比较难理解；服务之间可能会有循环依赖；因为需要订阅事件，所以随着服务的变更可能有漏定的风险，每次需要明确评估影响，保持下游业务订阅的完整性。

SAGA 实践

SAGA 使用条件

SAGA 的使用上有一些限制条件：

1. SAGA 只允许两个层次的嵌套，顶级的 SAGA 事务和简单子事务。
2. 每个子事务之间是独立的，各自保证原子性。
3. 全局SAGA之间无法保证隔离性。
4. 补偿事务Ci只能从语义或者业务角度撤消了事务Ti的行为，但未必能将数据库返回到执行Ti时的状态。

关于补偿，说明一下。比如用户使用了红包来支付，但是部分订单退款，这时候我们无法补发原价值的红包。但是我们可以在业务上进行补偿，比如重新拍发一个对应退款金额的新红包。

ACID特性保证

SAGA 不提供ACID保证，因为原子性和隔离性不能得到满足，具体如下。

• 原子性（Atomicity）：只能业务上保证，不是严格的原子性。
• 隔离性（Isolation）：不能保证，不同SAGA事务之间中间结果可见。
• 一致性（Consistency）：保证最终一致性，但是中间状态会不一致。
• 持久性（Durability）：可以保证。

TCC对比

1. 看起来和TCC很相似，但是和TCC相比，SAGA 没有“预留”动作，每个子事务的 T 操作直接提交数据。
2. 因为没有预留数据，所欲 TCC 可以保证隔离性，但是 SAGA不行。
3. 但也因为没有预留动作，SAGA 在一些场景下实现简单，并且少一次网络通信过程。
4. SAGA适合无法提供 Try 接口的场景（比如对接银行），这点TCC无法做到。

适用场景

• 事务参与者含第三方或者无法提供TCC预留接口。

• 事务流程长，涉及系统多。

• 常用于银行、金融、贷款，或者技术架构不统一的复杂分布式场景。

优缺点

优点：

• 性能较高，无需锁定资源，子事务直接提交。

• 采用事件驱动模式，吞吐量更高。

缺点：

1. 无法提供原子性和隔离性保证。
2. 有一定业务侵入性，逆向接口不一定好实现。
3. 如果采用命令协调模式有单点风险，需要做好日志记录和重试。

最后，欢迎大家提问和交流。