Sagas的业务实现逻辑是什么

今天就跟大家聊聊有关Sagas的业务实现逻辑是什么，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

在上图中，TDB会有两个表。也就是说，事务补偿能够成功实现，主要靠TDB中的这两张表！：

• 事务状态表（记录事务组状态；txid、state、timestap）、

• 事务调用组表（记录事务组中每一次调用和相关参数；txid、actionid、callmethod、pramatype、params）。
  

接下来，我们介绍上面两个表每个字段的含义：txid是主键、state表示事务状态（例如：1开始 2成功  3失败  4补偿成功 ）、actionid是操作次数的id、callmethod是补偿接口、调用服务的类型（如web/RPC）、params是具体数据包的调度参数。

而事务补偿，就是当事务调用失败，事务拦截器修改事务组状态（state）。然后由TM发起，分布式事务补偿服务异步执行补偿。

上面的内容比较抽象，我们结合场景进行说明，还是以下图为例。

大魏在京东购物，这是一个分布式事务。这个时候，proxy生成事务组表的一行数据，并且记录（t1代表分布式事务1）：

接下来，要正式干活儿了。Proxy记录事务A的调用信息，写入事务组表：

记录完毕后，A做本地事务：

A执行成功后，Proxy用类似的方式管理B，以此类推C。

Proxy在事务调用表中记录B的调用内容：

B本地事务执行：

Proxy在事务调用表中记录C的调用内容：

然后C执行。

当C本地事务执行成功后，Proxy将会修改TDB中的信息：

修改前：

修改后：

也就是说，标记分布式事务执行成功。

但是，如果在上面的步骤中，C执行失败呢？

首先，Proxy会将TDB中的事务组表进行如下修改，将状态从1开始修改为3失败：

修改前：

修改后：

接下来，Schedule（即TM）会扫描到（定期扫描）t1失败（状态为3）。然后Schedule发现T1在事务调用表有2个关联的本地事务（C做失败已经自动rollback）

接下来，根据事务调用表中的pramatype字段，RPC Client调用补偿接口，对事务进行补偿。

先补偿B：

再补偿A：

最后，补偿完毕后，proxy修改TBD中的事务组表，将state从3改成4，代表补偿成功。

我们上述逻辑，结合业务逻辑组件进行结合。这次我们把业务逻辑模块换一下。京东购物，选中货物后，库存会被锁住（A）、然后支付的时候，会选择红包或者京东卡，会有减红包或减京东卡余额的操作（C）、最后成功创建订单（C）。

具体参考下图：

总结：在本文中，我们介绍了Saga的业务实现逻辑。关于Proxy的作用：

Proxy的实现，在Java中是通过@around实现的。

• 交易业务逻辑层加注解，SpringBoot可以基于@tx（可以和@around协同工作）和@Transactional（通过拦截器TransactionInterceptor实现）。

• Proxy 作为拦截器，它在真正业务逻辑被调用之前 , 生成一 个全局唯一TXID 标示事务组， TXID 保存在全局变量里，  事前拦截器写入，并向 TDB 写入 TXID 并把事务组置为开始状态，完成业务操作后清除 TXID 标 识.

• 交易业务逻辑层调用数据访问前，通过 RPCProxy代理记录当前调用请求上下文参数。

• 如果业务成功，调用记录删除

• 如果调用异常，根据记录反向补偿

看完上述内容，你们对Sagas的业务实现逻辑是什么有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注亿速云行业资讯频道，感谢大家的支持。