whutjiajiao 2019-09-23
作者:陶陶技术笔记 链接:https://www.cnblogs.com/zlt2000/p/11570917.html?utm_source=tuicool&utm_medium=referral
一、背景
在微服务架构中,我们常常使用异步化的手段来提升系统的 吞吐量 和 解耦 上下游,而构建异步架构最常用的手段就是使用 消息队列(MQ) ,那异步架构怎样才能实现数据一致性呢?本文主要介绍如何使用 RocketMQ 的 事务消息 来解决一致性问题。
RocketMQ是阿里巴巴开源的分布式消息中间件,目前已成为 Apache 的顶级项目。历经多次天猫双十一海量消息考验,具有高性能、低延时和高可靠等特性
PS:同步场景怎样保证一致性?请看文章《 Spring Cloud同步场景分布式事务怎样做?试试Seata 》
二、MQ选型
可以看到在 业务处理 方面来说 RocketMQ 优于其他对手,而且原生支持 事务消息
PS:业务系统用的是其他 MQ 产品但是又需要 事务消息 怎么办?学习原理自己开发实现!
三、什么是事务消息
例如下图的场景:生成订单记录 -> MQ -> 增加积分
我们是应该先 创建订单记录 ,还是先 发送MQ消息 呢?
上面的 方式二 看似没问题,但是 网络是不可靠的 !如果 MQ 的响应因为网络原因没有收到,所以在面对不确定的结果只好进行回滚;但是 MQ 端又确实是收到了这条消息的,只是回给客户端的 响应丢失 了!
所以 事务消息 就是用来保证 本地事务 与 MQ消息发送 的原子性!
四、RocketMQ事务消息原理
主要的逻辑分为两个流程:
逻辑时序图
五、异步架构一致性实现思路
从上面的原理可以发现 事务消息 仅仅只是保证本地事务和MQ消息发送形成整体的 原子性 ,而投递到MQ服务器后,并无法保证消费者一定能消费成功!
如果 消费端消费失败 后的处理方式,建议是记录异常信息然后 人工处理 ,并不建议回滚上游服务的数据(因为两者是 解耦 的,而且 复杂度 太高)
我们可以利用 MQ 的两个特性 重试 和 死信队列 来协助消费端处理:
重试 死信队列 死信队列
因为有 重试 所以消费者需要实现 幂等性
六、分布式事务场景样例
下面就用刚刚提到的场景: 生成订单记录 -> MQ -> 增加积分 ;来简单讲一下 Spring Cloud中应该怎么做,详细代码请 下载demo 查看。
PS:怎样安装部署RocketMQ可以参考《 Apache RocketMQ 消息队列部署与可视化界面安装》
6.1. 引入依赖
使用 spring-cloud-stream 框架来访问 RocketMQ
Spring Cloud Stream 是一个构建消息驱动的框架,通过抽象的定义实现应用与MQ消息队列之间的解耦,目前支持 RabbitMQ 、 kafka 和 RocketMQ
6.2. 开启事务消息
消息生产者需要添加 transactional: true 开启 事务消息
6.3. 订单服务发送half消息
因为开启了 事务消息 所以这里发送的是 half消息 对于消费端是 不可见 的
6.4. 订单服务监听half消息
使用 @RocketMQTransactionListener 注解监听 半消息 ,并实现 RocketMQLocalTransactionListener 接口,该接口有两个方法
如果提交事务消息失败,需等待约1分钟左右 事务回查 方法才会被调用
6.5. 积分服务消费消息
注意:因为有 重试 ,这里如果是真实的业务需要自行实现 幂等性
6.6. 消费死信队列预警
监听并消费死信队列中的消息,用于记录错误日志,并且预警通知运维人员等
6.7. 测试用例
demo中提供了3个接口分别测试不同的场景:
七、demo下载地址
https://gitee.com/zlt2000/microservices-platform/tree/master/zlt-demo/rocketmq-demo/rocketmq-transactional
关注作者:JAVA高级程序员
专注分享:(高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等技术...)
每天Java一下,成为架构师!