今天就跟大家聊聊有关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的业务实现逻辑是什么有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联行业资讯频道，感谢大家的支持。