RocketMQ高手之路系列之八:RocketMQ之事务消息(一)

本文阅读 6 分钟
首页 代码,Java 正文

引言

事务的概念就不用多说了,我相信阅读文章的童鞋都是有着非常深刻的认识。我们都知道MQ可以实现微服务之间的异步以及解耦,那么引入MQ之后,如何实现微服务之间的数据一致性是一个值得思考的问题。事务消息将分为三篇文章进行介绍,本文主要介绍RocketMQ的事务原理,第二篇文章主要分析事务消息源码实现分析。在第三篇文章中将提供一种优化方案,解决RocketMQ对于业务代码侵入较大的问题。

  • RocketMQ事务原理
  • 总结

一、RocketMQ事务原理

1、消息发送问题分析

为了方便大家理解,我们以日常生活中的订单服务来进行原理的说明。当我们支付订单之后,我们账户的购物积分也会进行相应的积分调整。我们结合下面的订单服务、RocketMQ、积分服务的简化交互图来看下,如果没有事务消息,这样的服务间交互有没有问题。 img 可能有的童鞋会说,这不是很简单嘛,肯定是订单服务先执行本地事务,更新订单信息。然后再发消息到MQ中,积分服务消费消息更新积分啊。但是事实上并没有这么简单。

如果我们订单服务直接更新的了订单信息并进行持久化,而后在发送订单信息到MQ中。如果此时MQ服务不可用,消息发送报错,无法将订单消息发到MQ中,也就意味着积分服务不能收到订单信息,也就不会进行相应的积分操作。此时就会出现订单信息与积分信息数据不一致的问题。那么RocketMQ是怎么解决这个问题的呢?

2、半消息

实际上RocketMQ提供了一种half消息的机制,订单服务发送half消息到MQ中,这个half消息是不被消费者所见的。怎么理解这个half信息呢,按照我自己的理解,就是它实现了一半的消息功能,只在生产端可见,在消费端不可见。那么这个half消息是怎么实现在MQ中不被积分服务所见的呢?

订单服务发送half消息,并不是将消息投递到积分服务订阅的topic,而是将消息投递到RocketMQ中的RMQ_SYS_TRANS_HALF_TOPIC对应的messeageQueue。由于积分服务并没有订阅这个Topic,所以这个消息对于积分服务是不可见的。

另外有个OP_TOPIC用于记录对应half消息的commit/rollback状态。大致的交互如下如所示:

img

3、事务消息流程

交代完一些背景知识之后,我们来具体分析下事务消息的流程。订单服务先发送half消息到MQ中,相当于检查下此时RocketMQ是否可用。如果此时half消息可以正常发送到MQ中,订单服务可以收到响应。此时订单服务可以进行本地事务处理,更新订单信息。同时订单服务提供事务执行结果的接口用于RocketMQ进行回调。 img

如果订单服务half消息发送失败了,由于网络原因或者MQ挂了,那么此时需要执行一些回滚操作,让订单进行关闭。因为订单信息无法通知到下游服务了。

那么如果half消息已经写入MQ中,但是本地事务执行失败又该怎么办呢?也就是说当订单服务接收到half消息写入成功的响应后,更新订单信息时发生了异常,无法完成状态更新。那么此时订单服务需要发送rollback的请求给RocketMQ,通知其间原来的half信息进行删除。如果本地事务执行成功,则需要发送commit请求给RocketMQ,RocketMQ会将原先存在RMQ_SYS_TRANS_HALF_TOPIC中的消息重新投递到积分服务订阅的TOPIC中去,这样积分服务就可以正常消费信息进行下一步的积分操作了。

再考虑一种情况,如果订单服务发送commit或者rollback请求未正常投递到RocketMQ中,RocketMQ不知道half消息到底是对应的本地事务到底是执行成功了还是执行失败了。针对这种情况,订单服务需要提供状态回查接口,RocketMQ定时检测是否还有没有处理的half消息,当存在这样的消息时,RocketMQ调用会查接口确认本地事务执行情况。执行失败的则删除half消息,执行成功则重新投递消息。

二、总结

最后用一张完整的交互图来总结下事务消息的整体流程,如下所示: img

本文为互联网自动采集或经作者授权后发布,本文观点不代表立场,若侵权下架请联系我们删帖处理!文章出自:https://blog.csdn.net/Diamond_Tao/article/details/108057796
-- 展开阅读全文 --
大白话讲解JDK源码系列:从头到尾再讲一遍ThreadLocal
« 上一篇 01-30
KillDefender 的 Beacon 对象文件 PoC 实现
下一篇 » 02-09

发表评论

成为第一个评论的人

热门文章

标签TAG

最近回复