浅谈实际开发中常用的分布式事物处理

浅谈实际开发中常用的分布式事物处理


前言

随着微服务的流行,越来越多系统不在是单体结构,根据业务和功能拆分成不同微服务,这就导致了,一个业务涉及多个微服务调用,业务之间的解耦,依靠spring框架提供的事物@Transactional无法处理。因此在多服务分布式场景下,如何保证事物数据的一致性,从而引入了分布式事物概念


一、分布式事物

网上有很多中解决方案,比如

1.两段式提交2pc: 通过引入一个协调节点,由协调节点先访问多个服务是否可用,如果可用,则全部请求提交。

2.tcc补偿方案:try-confirm-cancel.  先尝试锁资源,尝试成功提交事物并释放锁资源,提交失败,释放锁资源。

3.本地消息表:使用消息记录表+mq消息补偿机制。根据消息记录表配合定时调度任务,保证发送到mq.  mq消费后。在通知修改消息记录表。

4.使用RocketMQ,,这个不常用,可自行搜索

5.订阅数据库日志 binlog.  通过订阅数据库的日志,通过中间件通知其它业务模块

二、常用方案

1.使用记录表+mq机制

在这里插入图片描述

第一步:执行业务A,保存记录表1,然后发送mq通知B
第二步:B收到消息,保存记录做幂等,执行业务。
第三步:执行成功或者失败后,发送mq,通知A
第四步:A收到消息,更新记录表1,确认是成功,还是回滚

A保证发送消息通知到MQ
MQ保证消息交给B
B处理之后,不管成功还是失败。再次发送MQ通知A
A根据结果,判断是成功还是回滚。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值