使用消息队列实现分布式事务-公认较为理想的分布式事务解决方案

最新推荐文章于 2025-06-27 23:35:39 发布
最新推荐文章于 2025-06-27 23:35:39 发布
阅读量205 收藏
点赞数

https://www.cnblogs.com/taiyonghai/p/6094350.html

分布式事务了解吗？你们是如何解决分布式事务问题的？
黎明就要到来
05-26 825
金融核心等业务可能会选择 TCC 方案，以追求强一致性和更高的并发量，而对于更多的金融核心以上的业务系统 往往会选择补偿事务，补偿事务处理在 30 多年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。如果你要操作别的服务对应的库，不允许直连别的服务的库，违反微服务架构的规范，你随便交叉胡乱访问，几百个服务的话，全体乱套，这样的一套服务是没法管理的，没法治理的，可能会出现数据被别人改错，自己的库被别人写挂等情况。这种方案说实话几乎很少人使用，我们用的也比较少，但是也有使用的场景。
分布式事务
Mr.xing的博客
02-04 734
一个大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据存储的数据一致性。
基于RabbitMQ消息队列的分布式事务解决方案
02-24
介绍Rabbitmg用于解决分布式事务必须掌握的5个核心概念一款分布式消息中间件，基于erlang语言开发，具备语言级别的高并发处理能力。和Spring框架是同一家公司。支持持久化、高可用1.Queue:真正存储数据的地方2.Exchange:接收请求，转存数据3.Bind:收到请求后存储到哪里4.消息生产者:发送数据的应用5.消息消费者:取出数据处理的应用分布式事务是一个业务问题，不能脱离具体的场景。●基于数据库XA/JTA协议的方式需要数据库厂商支持;JAVA组件有atomikos等●异步校对数据的方式支付宝、微信支付主动查询支付状态、对账单的形式;●基于可靠消息(MQ)的解决方案异步场景
基于消息队列的分布式事务解决方案
勇往直前的专栏
05-13 815
前两天发了工资，第一反应是想着要给远方的女朋友一点惊喜！于是打开了平安银行的APP给女朋友转点钱！填写上对方招商银行卡的卡号、开户名，一键转账！搞定！在我点击的那瞬间，就收到了app的账户变动的提醒，并且出现了图一所示的提示界面：“处理中，正在等待对方银行返回结果……”。嗯！毕竟是跨行转账嘛，等个几秒也正常！脑海开始浮现出女朋友收到转账后惊喜与感动的画面！ 然而，一切并没有那么顺利，刚过一会儿，APP却如图二所示的提示我“由于收款人户名不符”导致转账失败！ 刚刚都已经从我卡里扣过钱了，现在却提示
分布式事务解决方案总结：本地消息异步确认、可靠消息最终一致性、最大努力通知
最新发布
码到三十五
06-27 2432
本文从实现原理、技术细节和适用场景三个维度对比了三种主流分布式事务解决方案。本地消息异步确认方案通过"本地事务+消息表"实现最终一致性，适合订单与库存解耦场景；可靠消息最终一致性基于消息队列的"半消息"机制，适用于支付等强一致性场景；最大努力通知方案采用"重试+补偿"机制，多用于第三方回调等非核心链路。文章还提供了详细的方案对比表格，指导读者根据一致性强度、实现复杂度和具体业务需求进行选型，如金融交易优先选可靠消息方案，高并发场景可考虑本地消息表方
消息队列解决分布式事务
Blogs of imWalker
12-21 1475
消息队列解决分布式事务 本地消息表：通常处于同一张数据表，通过事务触发器就能实现，但无法解决两张表处于不同的数据库问题 begin transaction: update User set account = account - 100 where userId = 'A' insert into message(userId,amount,status) values('A',100,1) ...
使用消息队列解决分布式事务一致性问题
woaiwym的博客
06-11 3690
如何可靠保存凭证（消息）　　有两种方法：业务与消息耦合的方式　　支付宝在完成扣款的同时，同时记录消息数据，这个消息数据与业务数据保存在同一数据库实例里（消息记录表表名为message）；12345Begin transaction         update A set amount=amount-10000 where userId=1;         insert into message...
分布式事务解决方案---消息队列
lhenchem的博客
01-09 432
通过MQ实现分布式事务 我们以简单的外卖系统逻辑举例 一、引入MQ之前的分布式架构 这个时候就会发生分布式事务问题，订单系统和配送系统的相对独立的，假设订单系统调用配送系统后超时了，然后订单系统异常回滚了，但是配送系统还是正常处理了，这就导致了事务问题，数据不一致了。 具体我们看代码示例： 订单系统： ...
【分布式事务】一、分布式事务概念、解决方案，一文彻底搞懂分布式事务
技术分享博客，工作经验，技能学习分享（多做一些不会的，会有意向不到的收获，IT高手不可能永远只做会的）
11-06 1214
【分布式事务】分布式事务概念、解决方案，一文彻底搞懂分布式事务
分布式事务：从理论到实践（一）
m0_38017860的博客
05-28 447
分布式事务：从理论到实践（一）从集中式到分布式20世纪60年代大型主机被发明出来，凭借其安全性和稳定性的表现成为主流。但从20世纪80年代以来，计算机系统向网络化和微型化的发展日趋明显，传统的集中式处理模式越来越不能适应人们的需求。集中式最明显的问题就是单点。随着PC机性能的不断提升和网络技术的快速普及，大型主机的市场份额变得越来越小，很多企业开始放弃原来的大型主机，而改用小型机和普通PC服务器来搭建分布式计算机。分布式什么是分布式系统？“分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅
redisson分布式锁与spring注解事务共用产生的一系列问题，及对应解决方案
阿啄debugIT
03-10 1451
前言 有锁才有自由，生活中不存在绝对的自由，绝对的自由通常对应的无序和混沌，只有在道德、法律、伦理的约束下的相对自由，才能使人感受到自由。 而在多线程编程中，锁是至关重要的，锁就是道德，就是法律约束，没有锁的多线程环境将会是混乱的，所有线程都在争夺资源，最后的结果就是导致系统崩溃，而有了锁之后，多线程环境才能稳定高效的工作。 事故现场 某些原因，获取锁失败-------没有在至少N/2+1个Redis实例取到锁，或者取锁时间已经超过了有效时间），客户端应该在所有的Redis实例上进行解锁（即便某
分布式事务---消息队列解决方案（本地消息表）
as4566的博客
10-17 2124
这一章我们介绍下分布式情况下进行事务的处理的方法----消息队列异步解决方案，也通过这个方案我们聊一聊分布式中的BASE理论在这里的体现。 对于事务我不多加介绍，分布式事务有几种解决方案如：2PC（两阶段提交），3PC（三阶段提交），补偿事务（TCC），消息队列异步。但是考虑到分布式下各种异常情况考虑下，常见生产方案一般都是消息队列异步解决方案，使用本地消息表保证异步的消息一致性，我们结合分布式理论聊聊消息队列异步解决方案。
分布式事务解决方案之消息队列
笙箫的博客
09-26 616
本方案是将分布式事务拆分成多个本地事务来完成，并且由消息队列异步协调完成，如下图： 下边以下单减少库存为例来说明： 1、订单服务和库存服务完成检查和预留资源。 2、订单服务在本地事务中完成添加订单表记录和添加“减少库存任务消息”。 3、由定时任务根据消息表的记录发送给MQ通知库存服务执行减库存操作。 4、库存服务执行减少库存，并且记录执行消息状态（为避免重复执行消息，在执行...
分布式事务（五）———可靠消息队列解决方案
共勉
09-04 2743
分布式事务之可靠消息队列解决方案，本文融合本地消息事务表、RocketMq、最大努力通知三种基于消息队列实现的解决方案
基于消息中间件解决分布式事务的开源框架Myth
兰陵笑笑生
12-21 3772
基于消息中间件的解决分布式事务框架：https://github.com/yu199195/myth 1.rpc框架支持 : dubbo,motan,springcloud。 2.消息中间件支持 : jms(activimq),amqp(rabbitmq),kafka,roceketmq。 3.本地事务日志存储支持 : redis,mogondb,zookeeper,file,mysql ...
基于消息的分布式事务简单方案
shuipinglp的专栏
05-30 1974
System-A为主系统 流程描述 1. system-A执行本地事务， 发送msg到redis，此时msg状态为unknown(这里全是unknown状态的msg，消息需要持久化，只有msg存在，即使system-b处理失败也可以有其他方式处理，一般是人工) 2.1本地事务提交 2.1.1 更改redis的msg状态为提交，从老的内存队列删除，并放入另一个内存队列(这里
消息队列进阶-2.分布式事务解决思路汇总
爱吃知识的土豆倪的博客
11-29 1163
锁粒度完全由业务自己控制，目的是解决复杂业务中，跨表跨库等大颗粒度资源锁定问题。TCC把事务运行工程分为了Try（一般是做一些预留资源或者锁定资源的动作） ，如果每一个分支都可以锁定成功，那么就可以执行下一步的confirm,如果有失败的呢，就要执行cancel。每个阶段的逻辑由业务代码控制，避免了长事务，可以获取更高的性能。这个主要是基于业务层面的事务控制，每个事务分支（订单服务、库存服务）都需要自己去实现对应的try。confirm/cncel 接口，侵入比较强。
微服务架构的分布式事务解决方案（3）--常规MQ队列消息的处理流流程和特点（基于可靠消息的最终一致性）
红烧咸鱼的博客
04-22 587
MQ队列消息模型的特点 由上图可以看到，
分布式事务解决方案(总览)
cyy_ln1001的博客
04-20 351
原帖 https://blog.youkuaiyun.com/wuzhiwei549/article/details/79787866 下面的使用 https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html 总览 本系列针对分布式事务提出三种解决方案：可靠消息最终一致性、最大...
利用事务消息解决分布式事务：MQ实践
"本文主要探讨了消息队列中利用事务消息来实现分布式事务的方法和重要性，以电商购物流程为例，分析了数据一致性的问题，并介绍了几种常见的分布式事务实现方式，如2PC、TCC和事务消息。" 在分布式系统中，消息队列...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值