一.分布式事务的业务场景
现在好多项目都是拆分成多个模块进行开发的,由于一些业务的原因,各个模块有着或多或少的关联.比如在一个电商项目中,订单模块与配送模块之间,生成一个订单就要通知到配送模块进行安排物流配送.而订单模块与配送模块各是一个单独的工程,他们之间通过http调用接口进行通讯.在这个业务场景下,生成订单的过程与安排物流进行配送的过程按道理来说是应在一个事务中的,要成功都成功,要失败都失败.显然,这种事务不像在一个数据库中那样用一个注解就可以搞定.跨项目中的事务,就叫做分布式事务.
二.分布式事务该如何解决
之前面试时经常会被问到,分布式事务该如何解决?总是支支吾吾,答不上来,因为自己没有一个清晰的思路,知识储备不够.最近通过学习,知道了分布式事务可以通过消息中间件来解决,今天我们就以rabbitmq为例来实现一个分布式事务异步解决方案.由于时间有限,在这里我就不贴代码了,只具体说明下思路.
三.使用rabbitmq实现分布式事务
1.两个项目之间进行通讯,我们以消息的形式进行传送.还拿电商的项目举例,订单端和配送端.订单端生成订单后要把消息发送到rabbitmq中的queue里面,这里就要确保一定发送成功.如何确保呢?我们在本地要建一张消息发送记录表,里面有发送的状态,发送的内容,发送时间字段.rabbitmq有一个消息发布确认机制,我们要配置开启,这样在订单端消息发布成功后,会有一个更新本地消息表里的发布状态.如果由于网络的原因消息发布确认没有成功,这时候要用一个定时器定时去重发本地消息表没有发送成功超时的消息.
2.在配送端也就是消息消费端接收到消息并处理成功后要手动Ack,告诉rabbitmq消息消费成功可以删除了.如果在消费的过程中捕获到异常了,这时消费端要nack然后通知rabbmit重新发送消息,在这里要记录好nack的次数也就是重试次数,如果重试超过一定次数则不再重新发送,可以将此消息放在一个队列或者数据库里,然后人工干预.
3.在配送端消息消费的过程中一定要做好幂等性,可以把消费记录存放在redis中,如果消息消费过了就不再重新消费.
这种分布式事务解决方案可以解决大部分业务场景,但对于实时性要求较高的业务场景就不适合.分布式事务的解决方案还有很多种,还需要我们不断的去学习.
