十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
今天就跟大家聊聊有关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的业务实现逻辑是什么有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。