如果你还不知道SAGA,那这篇不容错过!|分布式事务系列(五)

这是分布式事务系列的第五篇,如果之前文章没读请自行前往。精华专题,强烈建议收藏。

‍本文详细讲解了分布式事务解决方案——SAGA。

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. 如果采用命令协调模式有单点风险,需要做好日志记录和重试。

后,欢迎大家提问和交流。

相关文章