首页>>后端>>Spring->springcloud进阶:四种分布式事务模式之SAGA模式(三)

springcloud进阶:四种分布式事务模式之SAGA模式(三)

时间:2023-11-30 本站 点击:0

   0.引言

之前我们已经讲解了四种分布式事务模式的前两种:AT模式和TCC模式,如果对于这两种模式有疑惑的,可以翻看专栏之前的文章

今天我们接着来讲讲SAGA模式

1. SAGA模式

saga的定义是“长时间活动的事务”,是普林斯顿大学教授Hector & Kenneth发表的论文《sagas》中提出的概念。它的思想是允许分布式事务在全部提交前提前释放占用的某些资源

其实我看到saga这个名称的第一印象,是想到了圣斗士星矢里的沙迦,沙迦以强悍的实力著称。而SAGA模式也专用于解决长事务资源占用难题

什么是长事务

所谓长事务,就是需要长时间执行的事务,这类事务往往需要访问大量的数据对象,其执行周期甚至能达到几周或几月。但传统的事务执行时需要锁定占用资源,如果在这样的一个场景下,资源被长期锁定,带来的性能消耗可想而知。因此我们引入了SAGA模式来解决长事务。

SAGA的工作原理呢,就比较好理解了:

SAGA模式由一串本地事务组成,每个本地事务都有自己回滚数据的补偿事务。事务之间串型执行,当正向执行的某一个事务出现报错,那么将执行这个事务的补偿事务,并且逆行执行之前事务的补偿事务

SAGA也是有两阶段的,一阶段是正向事务,二阶段是补偿事务 saga模式依然要求我们自己实现正向服务和补偿服务。但是它于TCC模式的区别之处在于:

saga的模式设计使得它天然适合于长流程的业务。TCC要实现同样的长流程的话,需要多写一个confirm操作,并且要考虑如何将业务拆分为两部分

saga模式在正向服务中时就已经提交了本地事务了,而补偿事务也比较好实现,将正向服务的结合逆向补偿即可。 比如正常服务是update product set price=20 where price=30 and id=1;  那么补偿服务就是update product set price=30 where price=20 and id=1;

比起TCC模式,saga模式更适用于一些老服务、第三方服务或者其他无法改造的服务,要接入到我们的分布式事务中时,就可以将其作为一个正向服务存在,而直接实现他的补偿服务即可。而TCC因为要对业务进行拆分为try-confirm-cancel,所以它不适用于不可改造的服务

同时,saga模式同样不需要全局锁,只需要结合本地事务加本地锁即可,所以性能依旧有保证。

1.1 SAGA模式的三种事务类型

1.1.1 可补偿性事务

所谓可补偿性事务,也就是可以使用、需要使用补偿事务来回滚数据的事务

比如说下订单,就需要删除订单的补偿事务,因此下订单就是一个可补偿性事务

1.1.2 关键性事务

关键性事务是saga执行的关键点,如果关键性事务运行成功,则saga将一直运行到完成。关键性事务不一定是个可补偿性事务或者可重复性事务,但是他可以是最后一个可补偿的事务或第一个可重复的事务 ———《微服务架构设计模式》

通过书中的描述,我们知道关键性事务的定义从结构上理解,是处于可补偿性事务和可重复性事务的中间。

具体把哪个事务定义为关键性事务,还要根据具体的业务情况而定,我们可以通过以下标准来判断

从结构上是否处于可补偿事务和可重复事务之间

从业务上该事务是否能表示整个业务执行成功的转折点

1.1.3 可重复性事务

关键性事务之后的事务就是可重复性事务,不需要回滚,并且保证能够执行完成。所以我们会通过一些机制来保证这类事务一定能执行成功,比如重试机制。

1.2 SAGA模式服务调用机制

我们上述说了,saga模式是通过正向服务、补偿服务之间的正向串性和逆向串性来实现的。这些服务之间的调用链很长,我们通过什么方式来实现调用呢?

1.2.1 每个服务给后续服务发送消息

我们让每个服务来通知后续的服务进行操作,这是我们串行服务最常想到的做法。但这样有个很明显的问题,那就是具体做起来的困难性。

想象一下,如果我们要对事件进行调用,我们不但要考虑正向的服务调用,还要考虑逆向的补偿调用,特别是要再考虑逆向的补偿调用,一些简单的串型业务设计起来很简单,但是某些交错复杂的业务会非常麻烦。同时服务间的耦合性又增强了。

所以我们做了一个增强版,那就是前一个服务执行完成后发送消息,后一个服务通过订阅消息的模式来实现服务的协调。我们引入了MQ的概念来解决耦合性问题。

1.2.1.1 好处

简单:这种模式的实现相对来说逻辑清晰,当然这里简单只能说针对于部分业务而言,某些比较复杂的场景的话,这样的设计反而很难实现,相互之间的订阅交错复杂。

解耦:加强版中引入了消息订阅,以此降低了耦合性

1.2.1.2 坏处

消息死循环:服务之间通过订阅消息来触发调用,处理不当,容易造成相互订阅的情况,从而出现循环依赖或消息死循环问题。

面对复杂业务的局限性:上述也说了,当业务调用交错复杂时,我们通过订阅消息的形式来获取调用事务的时机,但是也决定了,每个事务都要订阅会影响它的事件消息,复杂场景时会导致我们需要考虑的东西很多,就需要非常强大的逻辑能力来支撑了,存在局限性。

难上手:想象一下,你接手上一个同事设计的稍微复杂一点的协同模式时,你需要花多久理清楚这里面的消息订阅的逻辑线。它的呈现并不直观,较难理解。

1.2.2 事件驱动器来协调

如果接触过过工作流设计的同学可能对这个东西比较熟悉,简单来说就是一个第三方组件,通过它可以进行拖拽化的流程设计,如下图所示。关于这个驱动器就不再多说了,感兴趣的可以去官方了解。 seata官方也提供了在线的模块设计工具:saga 事件驱动在线设计

1.2.2.1 好处

不会产生死循环:调用是单向的,驱动器会调用事务,但是事务不会调用驱动器,因此其调用关系完全交给驱动器去管理,也就没有了依赖循环的问题

理解简单:虽然设计器的使用学习有成本,但是我们针对其设计上的理解来说,更加容易理解上手。

业务逻辑更加简单清晰:事务协调完全交给了驱动器,业务代码无需关心,可以专注于业务需求上,降低了代码难度。

1.2.2.2 坏处

学习成本:存在一定的设计器的以及相关API的学习成本

1.3 SAGA模式如何保证事务隔离性

聊这个问题之前,我们得先了解,什么是事务的隔离性?

事务独立执行,不受其他并发操作影响就是事务的隔离性。

但如上述,SAGA中各个本地事务执行完就提交,所以是相对独立的,SAGA事务中的某一个事务的执行结果,是可以被其他业务操作或影响的。但一旦中间数据被其他业务修改了,再要回退时就会出现脏写而无法回滚。

因此SAGA模式下的分布式事务就没有隔离性了吗?那还能叫事务吗?出现脏写怎么办?

SAGA模式也提供了一种最终实现隔离性的思路,seata官方文档中的介绍是“宁可长款,不可短款”的原则。

这是什么意思??? 官方解释如下

业务流程设计时遵循“宁可长款, 不可短款”的原则, 长款意思是客户少了钱机构多了钱, 以机构信誉可以给客户退款, 反之则是短款, 少的钱可能追不回来了。所以在业务流程设计上一定是先扣款。

有些业务场景可以允许让业务最终成功, 在回滚不了的情况下可以继续重试完成后面的流程, 所以状态机引擎除了提供“回滚”能力还需要提供“向前”恢复上下文继续执行的能力, 让业务最终执行成功, 达到最终一致性的目的。

通俗来讲,就是不需要按照原路返回,只需要通过一定的措施让数据恢复之前的状态即可,也就是保证最终一致性即可。

那么具体有哪些方式呢?我们列举《微服务架构设计模式》中说明的处理方案,以下处理方案出自书籍中第4章第3节,有兴趣的同学可以翻看下书中原滋原味的解释

1.3.1 语义锁

说的直白点语义锁就是一个标记状态,该标记表示该记录未提交且可能发生改变,正向事务会在其操作的每一条记录中添加这个状态。

比如扣除库存时,给对应商品添加一个状态,当有其他事务访问这个商品时发现状态为锁定中,就不会再访问这个商品,会等待状态更新完成后再操作。其实就是一个手动加锁的过程。

执行成功的话,最后通过一个可重复事务或者定时任务将状态更新为已解锁,执行失败就通过补偿事务将状态更新为已解锁

这里的可重复事务,指的是不管执行成功还是失败都可以执行的事务,其执行不影响原本的数据记录。一般可重复性事务会放到最后执行。

1.3.2 交换式更新

把更新操作设计成可以按任何顺序执行,也就是说操作是可以交换的。

这样说明其实是很抽象的,我们举个例子来说明,比如下订单后,商品要扣减库存,正向事务是库存-10,

update product set inventory=inventory-10 where id=1;

那么将其补偿事务设计为库存+10。

update product set inventory=inventory+10 where id=1;

这样哪怕有其他事务操作污染了库存数据,但是因为更新的内容是纯数字的,不受其他事务的影响,且定位信息为id=1这一点无法篡改。当然我们要求这里没有删除商品的操作。

那么我们就称现在的正向事务和补偿事务是可以交换的。是不是稍微理解一点了,更新的交换性存在着很大的局限性,并不是所有的操作都可以设计为可交换的。

常见的交换性操作也就是数值、枚举值上的更新。因此不同的操作也需要我们结合不同的方案来设计隔离性。

1.3.3 悲观视图

悲观视图实际上并不是一个100%的方案,他的本意是说以最悲观的情况考虑事务被其他事务更改的可能性,然后重新排序saga事务的步骤,以此最大限度的较低脏写风险

所以这也就决定了,悲观视图是一个不那么完善的方案,并不能完全保证隔离性。所以能够应用到的业务也有限。

1.3.4 重读值

重读值的意思是在更新之前重新读取记录,可以通过维护一个计数器,比如版本号,来验证它是否发生改变,如果已经改变了那么事务中止或者重新启动。如果未改变那么继续执行。

其实了解乐观锁的同学应该闻到味儿了,没错,这玩意儿就是乐观锁的一种。

1.3.5 版本文件

《微服务架构设计模式》一书中是这样说明的:

版本文件对策之所以如此命名,是因为它记录了对数据执行的操作,以便可以对它们进行重新排序。这是将不可交换操作转换为可交换操作的一种方法

针对这个方案的理解,我们直接通过一个案例来解释:

我们有一个下订单的业务。我们现在还有一个取消这个订单的业务

当因为网络阻塞或者其他原因导致取消订单的业务先执行了,当下订单的业务后执行时就会创建一个订单,导致用户发起的取消操作变得无效了。从而产生了数据的不一致性

通过版本文件,我们将在取消订单的时候会记录这个取消操作数据,后续收到下订单的操作时会比较版本文件,来跳过订单的创建操作,其效果也就相当于将两个操作顺序调换了一下。以此保证了最后的数据依旧是订单被取消。

1.3.6 业务风险评级

最终的对策是基于价值(业务风险)对策。这是一种基于业务风险选择并发机制的策略。使用此对策的应用程序使用每个请求的属性来决定使用Saga和分布式事务。它使用Saga执行低风险请求,可能会应用前几节中描述的对策。但它使用分布式事务来执行高风险请求(例如涉及大量资金)。此对策使应用程序能够动态地对业务风险、可用性和可伸缩性进行权衡。

讲大白话,就是低风险的不容易出现脏读或者出现脏读也不影响业务的选择saga,高风险的对脏读敏感的选择其他分布式模式。动态地进行选择。

1.4 SAGA模式的补偿措施

与TCC模式类似,SAGA模式也涉及到如下几个问题

1.4.1 幂等性问题

所谓幂等就是操作一次和操作多次的执行效果是一样的。

想象一下,我们的库存扣除操作,如果因为某一步操作报错,导致需要回滚重试,结果每次重试都会重复扣减库存,那这样肯定是不对的。

所以为了保证我们在confirm,cancel中进行的重试机制不会使得我们的资源发生重复消耗,那么需要我们对方法做好幂等性处理:

比如说通过添加状态字段来判断是否执行过。当然这一点在seata等分布式框架中不用我们再手动实现,框架已经帮我们实现了。

1.4.2 悬挂问题

所谓悬挂问题,就是二阶段模式中,二阶段比一阶段先执行

这是怎么导致的呢?

我们拿下订单扣减库存的案例来说,在订单服务中调用商品服务的扣减库存方法reduceInventory时,通常通过RPC(feign)的方式来调用,那么如果调用时刚好网络堵塞,或者商品服务出现问题,导致调用失败,出现报错,TM会通知TC出现错误,TC会通知所有的RM进行本地事务回滚,也就是执行补偿事务。

当补偿事务方法执行完成后,正向事务方法偏偏连通了,又执行了,那么就出现了问题,这个正向服务之前的补偿事务都执行了,但又执行了一个多余的正向服务。

所有我们需要针对悬挂问题进行防悬挂处理,方案呢就是限制如果二阶段执行完成,一阶段就不能再执行。

seata中的解决方案是增加一个事务记录表,在补偿服务执行后往事务记录表中插入一条记录(xid-status)标记补偿服务已经执行过。此时正向服务进入时发现已经执行过回滚操作,则放弃正向服务的执行。

2. SAGA模式应用场景

适用于长事务业务场景

适用于需要接入老服务、第三方服务或者其他无法改造的服务的业务场景

需要操作更细分散在多个服务、系统中的数据的业务场景

文章中观点基于个人理解,部分知识点可供学习佐证的资料较少,如果理解有误,欢迎指正!如果本文对你的学习有帮助,不妨点赞支持一下

原文:https://juejin.cn/post/7096494185699606542


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:/Spring/4471.html