如果你还不知道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,有三个需要注意的点:
Ti和Ci是幂等的,因为都需要重试以保证终一致性。 Ci 必须是能够成功的,否则SAGA将无法撤销影响,如果无法成功则需要人工介入做补偿。 Ti 和Ci的执行顺序可以交换,不保证Ti一定在Ci前执行,但是终执行效果相同,即子事务Ti影响被撤销。
这里着重说一下第三点,为什么要求Ci可以在Ti之前执行?因为网络之间的不稳定性,无法保证Ti一定执行,或者一定在Ci之前执行。具体来说,有以下三种执行情况。
正常情况:Ti先执行,Ci后执行。 Ti请求因为网络问题丢失了,彻底不会执行。 Ti执行超时,判断为执行失败,直到Ci执行前 Ti 都没有执行完成,导致出现Ci先执行的情况。
所以,有了第三点的要求,Ti 和 Ci 顺序可交换。
两种模式
通过阅读SAGA协议的具体内容,我们可以发现,实现的关键之一子事务之间的协调。首先我们要知道一个事务的开始,并且可以让子事务按顺序执行,并且在某个事务执行完后通知下一个子事务。如果有子事务执行失败,需要按照顺序执行补偿逻辑。
所以根据协调子事务的方法,可以分为两类:命令协调模式和事件编排模式。
编排(Choreography): 控制(Orchestration):
命令协调模式(Orchestration)
命令协调模式:由中央协调器集中处理事件的决策和业务逻辑排序,以命令或者回复的方式与每个参与服务进行通信,全权负责告诉每个参与者什么时候该做什么。
依旧以之前的电商为例:
事务发起者调用SAGA控制器开启事务(这里的控制器也可以由发起者兼任)。 SAGA中央协调器发起扣减库存,库存扣减结果返回。 SAGA中央协调器发起创建订单,订单创建结果返回。 SAGA中央协调器发起支付请求,支付结果返回。 SAGA中央协调器处理终结果,并返回给应用程序。
SAGA中央协调器预先知道完整的事务处理流程,这可以通过配置实现。如果任意子事务失败失败,它便向每个参与者发送命令来执行补偿操作Ci(或者执行重试-向前恢复)。
其缺点很明显,既然有中央协调器就会有单点问题。
但是优点也很多,主要有:服务之间的编排顺序明确,依赖关系简单,不会有循环依赖;耦合相对较少,参与者只需要依赖协调者接口,参与者之间没有直接依赖;参与者只需要关注自身业务,服务之间协调统一由协调器管理。
事件编排模式
事件编排模式:SAGA 中的参与者通过交换事件进行沟通,按照提前编排好的发布顺序决策和排序。
这种模式没有单点风险,由每个服务监听对应事件,并对事件做出反应。SAGA事务由应用程序发布个事件开始,中间服务接受到对应事件做本地事务的处理,然后继续发布事件。每一个事件由一个或者多个服务监听。当后一个服务执行本地事务并发布事件后,Application 收到后一个事件,事务结束,事件处理的顺序都是提前编排好的。具体参考下图:
电商订单的例子为例:
应用程序发起SAGA事务,以订单事件发布开始。 库存服务监听开始订单事件,扣减库存,成功后发布库存扣减事件。 订单服务监听库存扣减事件,创建订单,并发布订单已创建事件。 支付服务监听订单创建事件,进行支付,并发布订单已支付事件。 应用程序监听支付成功事件,SAGA事务结束。
事件/编排是实现 SAGA 模式的自然方式,它通过事件串联各个服务,实现了服务之间的松耦合。并且实现简单,只需要在执行本地事务时发布事件。如果事务涉及 2 至 4 个步骤,则可能是非常合适的。
但是有一些缺点:因为代码中没有明显的编排逻辑,所以可能会比较难理解;服务之间可能会有循环依赖;因为需要订阅事件,所以随着服务的变更可能有漏定的风险,每次需要明确评估影响,保持下游业务订阅的完整性。
SAGA 实践
SAGA 使用条件
SAGA 的使用上有一些限制条件:
SAGA 只允许两个层次的嵌套,的 SAGA 事务和简单子事务。 每个子事务之间是独立的,各自保证原子性。 全局SAGA之间无法保证隔离性。 补偿事务Ci只能从语义或者业务角度撤消了事务Ti的行为,但未必能将数据库返回到执行Ti时的状态。
关于补偿,说明一下。比如用户使用了红包来支付,但是部分订单退款,这时候我们无法补发原价值的红包。但是我们可以在业务上进行补偿,比如重新拍发一个对应退款金额的新红包。
ACID特性保证
SAGA 不提供ACID保证,因为原子性和隔离性不能得到满足,具体如下。
原子性(Atomicity):只能业务上保证,不是严格的原子性。 隔离性(Isolation):不能保证,不同SAGA事务之间中间结果可见。 一致性(Consistency):保证终一致性,但是中间状态会不一致。 持久性(Durability):可以保证。
TCC对比
看起来和TCC很相似,但是和TCC相比,SAGA 没有“预留”动作,每个子事务的 T 操作直接提交数据。 因为没有预留数据,所欲 TCC 可以保证隔离性,但是 SAGA不行。 但也因为没有预留动作,SAGA 在一些场景下实现简单,并且少一次网络通信过程。 SAGA适合无法提供 Try 接口的场景(比如对接银行),这点TCC无法做到。
适用场景
事务参与者含第三方或者无法提供TCC预留接口。
事务流程长,涉及系统多。
常用于银行、金融、贷款,或者技术架构不统一的复杂分布式场景。
优缺点
优点:
性能较高,无需锁定资源,子事务直接提交。
采用事件驱动模式,吞吐量更高。
缺点:
无法提供原子性和隔离性保证。 有一定业务侵入性,逆向接口不一定好实现。 如果采用命令协调模式有单点风险,需要做好日志记录和重试。
后,欢迎大家提问和交流。
相关文章