分布式事务的一种解决方案

本文探讨了分布式事务在电商项目中的应用场景,介绍了通过RabbitMQ实现分布式事务的异步解决方案,包括消息发布确认机制、消息消费端的手动Ack及重试机制,以及确保消息消费幂等性的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一.分布式事务的业务场景

现在好多项目都是拆分成多个模块进行开发的,由于一些业务的原因,各个模块有着或多或少的关联.比如在一个电商项目中,订单模块与配送模块之间,生成一个订单就要通知到配送模块进行安排物流配送.而订单模块与配送模块各是一个单独的工程,他们之间通过http调用接口进行通讯.在这个业务场景下,生成订单的过程与安排物流进行配送的过程按道理来说是应在一个事务中的,要成功都成功,要失败都失败.显然,这种事务不像在一个数据库中那样用一个注解就可以搞定.跨项目中的事务,就叫做分布式事务.

二.分布式事务该如何解决

之前面试时经常会被问到,分布式事务该如何解决?总是支支吾吾,答不上来,因为自己没有一个清晰的思路,知识储备不够.最近通过学习,知道了分布式事务可以通过消息中间件来解决,今天我们就以rabbitmq为例来实现一个分布式事务异步解决方案.由于时间有限,在这里我就不贴代码了,只具体说明下思路.

三.使用rabbitmq实现分布式事务

 1.两个项目之间进行通讯,我们以消息的形式进行传送.还拿电商的项目举例,订单端和配送端.订单端生成订单后要把消息发送到rabbitmq中的queue里面,这里就要确保一定发送成功.如何确保呢?我们在本地要建一张消息发送记录表,里面有发送的状态,发送的内容,发送时间字段.rabbitmq有一个消息发布确认机制,我们要配置开启,这样在订单端消息发布成功后,会有一个更新本地消息表里的发布状态.如果由于网络的原因消息发布确认没有成功,这时候要用一个定时器定时去重发本地消息表没有发送成功超时的消息.

2.在配送端也就是消息消费端接收到消息并处理成功后要手动Ack,告诉rabbitmq消息消费成功可以删除了.如果在消费的过程中捕获到异常了,这时消费端要nack然后通知rabbmit重新发送消息,在这里要记录好nack的次数也就是重试次数,如果重试超过一定次数则不再重新发送,可以将此消息放在一个队列或者数据库里,然后人工干预.

3.在配送端消息消费的过程中一定要做好幂等性,可以把消费记录存放在redis中,如果消息消费过了就不再重新消费.

 这种分布式事务解决方案可以解决大部分业务场景,但对于实时性要求较高的业务场景就不适合.分布式事务的解决方案还有很多种,还需要我们不断的去学习.

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值