3种使用MQ实现分布式事务的方式
1.保证消息传递与一致性
1.1生产者确保消息自主性
当生产者发送一条消息时,它必须完成他的所有业务操作。
如下图:
这保证消费者接受到消息时,生产者已处理完毕相关业务,也就是1PC的基础。
1.2 MQ保存并转发消息
消息标记为持久化,MQ将会利用保存并转发机制,来履行它与发送者之间的契约。
至于activemq高可用部分,详见另外一篇blog:https://my.oschina.net/floor/blog/1574213
一般MQ保存并转发的流程如下:
1.3消费者确认模式的选择
JMS提供的3中模式:
- auto_acknowledge:
消费者接收到消息后,立即自动向MQ发送确认消息。
- dups_ok_acknowledge
一条消息可以被多次消费,为了确保“一次且仅仅一次发送语义”。影响MQ性能。
- client_acknowledge
client端确认模式,手动确认消息已消费。
我是如何选择的:
dups_ok_acknowledge首先被排除,是因为它影响MQ的性能,我公司使用的activemq的性能本就一般,所以没有选择。
client_acknowledge 需要程序员编码确认消息被消费,可能存在1条消息很久没有消费掉,MQ堵住的情况,所以没有选择。
我们最终选择了auto_acknowledge ,原因是SImple is best。至于各位如何选择,按需而定吧!
1.4 漏洞与补救办法
经过之前的选择,我们的MQ流程图如下
稍微看下这个流程,大家就会发现,如果消费者,在自动确认消息后,在还没有消费消息时,若消费者挂掉了 ,由于MQ在auto_acknowledge下,当前生产者不会重新发送,这就产生了消息不一致的情况,即生产者端已处理,消费者端未处理的问题。
1.4.1. 2种方式处理消息不一致的情况
1.生产者再发一条消息,2.消费者查询下生产者业务是否完毕。2种方式均可实现。下边主要说下我公司的方式,方案不唯一仅供参考。
1.4.1.1 生产者再次发送,即定时任务补偿+幂等消费的方式
这里不使用MQ的dups_ok_acknowledge,是因为会影响MQ的性能。生产者再次发送方式存在3个问题:
- 生产者如何知道消费者没有消费一条消息?
- 生产者重新发送的频率是多少?
- 消费者如何处理重复的消息?
生产者如何知道消费者没有消费一条消息?
我们公司加入了一个event表,作为生产者与消费者之间的桥梁,用来维护消息的消费状态。event表的核心字段有,JMS队列名称,业务ID(我公司发送的消息都是业务ID,这里可以是业务bean),完成状态(完成,未完成),其他字段可按需而定。
生产者重新发送的频率是多少?
需要根据业务的实时性要求和消费者的能力和可以堆积的信息进行判断。经过分析与压测后,设定定时补偿的频率。
消费者如何处理重复的消息?
为何会出现重复的消息?
举例说明:
假设正常情况下一条消息消费需要2s(即单节点一分钟消费30条),我们3分补偿一次。
消息队列中已堆积了199条消息,第200条为当前发送的消息,为了简单仅仅考虑单一消费者的情况,当3分钟后,才消费完90条消息,还有堆积110,注意这个时候消费者还没有消费生产者3分钟前发送的消息,而补偿机制又发送了一条消息进入MQ,这就出现了消费者接受到重复消息的情况。
如何解决:
我在生产中的解决办法是在:利用event表,redis实现分布式事务锁,实现幂等消费。
当消费者接受到消息后,按如下步骤处理:
- 先查询event中的消息状态,如果消息存在且未处理,继续往下,若已处理直接返回。
- 利用redis,加锁,可以使用redission框架,也可以利用String类型的并设置失效时间的简单方式实现不可重入的锁,个人推荐推荐redission,但是我公司使用的是String类型的并设置失效时间的简单方式。
- 加锁成功后,再查询event中的消息状态,如果消息存在且未处理,继续往下,若已处理直接返回。
- 消费者处理自己的业务
- 更新event表中的状态为已处理
- 解锁操作
熟悉并发的朋友,会发现1-3步骤是DCL模型。
综上所述,以生产者再次发送的方式,保证消费者消费消息的整体流程如下:
看到这个模型图,可能觉得比较复杂,除了第8步,我们都可以在基类中实现了,并且由于event表数据独立于MQ,我们可以做一个监控(仅仅自己考虑公司没有实现),针对event,查询消息的消费情况,还能实现人工重发功能。以上模式,已在在生产模式中大量使用。
该模式的优点是可以确保消息最终一致性,生产者,MQ,消费者压力均不大,我们公司利用该模式实现核心业务,例如 票购买后的,拆票操作,追号触发追一期操作等。
1.4.1.2.消费者进行查询,推拉结合方式。
按理说消费者可以启动一个定时任务,查询生产者需要它消费的数据。模型类似之前,但是我公司并没有使用这种方式。因为是不想影响消费者的消费能力。
但是我们在通知业务中,实现了一种简易的推拉结合的方式,该方式个人认为使用面比较窄,但对通知业务有一定的适用性,在这里做下简要介绍
实现方式:
仅仅提供了一个http接口供用户查询,该http接口不一定在生产者,这里仅仅是画在生产者中。
其模型图如下:
这个模式使用的前提是:
消费者不消费数据,也对业务没有影响。
案例说明:
以通知3D的开奖号码为例:
生产者为抓取服务,当抓取服务,抓到的3D彩果后,针对每一个订阅者生存独一无二的消息数据,之后发送MQ。
消费者为push服务(实际上是调用第三方推送),接收的消息发给订阅的用户。
由于消息已入库,会在通知中心中展示,而用户是否接受到推送并不重要,他可以在app的消息中心中查询。
2.扩展,使用Event-Sourcing+MQ解决RPC类型的分布式事务‘
这个方式,来自于黄勇老师,我们目前在工作中用在用户支付与订单状态更新上,下边大部分的文字和截图的,都是来自黄勇老师的《架构探险-轻量级微服务架构下册》,在这里感谢黄勇老师的传道与解惑。
2.1什么是Event-Sourcing?
它是一种基于事件回溯的解决方案,一般将它应用在领域对象模型中。事件不可枚举,事件类型可以枚举。我们以event表示事件表,其大体内容如下:
- ID event的唯一表示
- EventType: 事件类型:CREATE,UPDATE,DELETE等。
- Model Name:表示模型名称:例如Foo,Bar等。
- MOdel ID: 模型ID
- Create Time 创建时间,精确到毫秒。
2.2实现方式:
第一步,操作模型表与时间表并写入消息队列
第二步,从消息队列中获取事件 ,操作模型表,若有异常,将事件再写入消息队列
第三步,从消息队列中获取原事件,操作事件表与模型表,进行“事件回溯”
回溯操作的特殊说明:
- INSERT,的逆向操作为DELETE,但是一般业务是标记删除,也就是说逆向操作为UPDATE。
- UPDATE,的逆向操作为UPDATE
- DELETE,由于一般是标记删除,所有逆向操作也是UPDATE。
2.3Event-Sourcing和MQ的RPC事务的控制流程图
总结
这篇文章,是我工作中使用MQ的感悟,可能存在不对的地方,欢迎各位指正。
本文3中模式,
- 定时补偿+幂等消费
- 推拉结合
- Event-Sourcing和MQ,实现RPC式分布式事务,(来自@黄勇 ,老师)
3种使用MQ实现分布式事务的方式的更多相关文章
- 关于利用MQ实现分布式事务的想法【转】
转自:https://www.jianshu.com/p/bafb09954f18 假设:消息服务不丢消息 场景 服务A 服务B 服务C 消息服务Q 伪代码 服务A中 transaction{ A本地 ...
- 使用 Docker 部署 Seata Server(分布式事务解决方式)
1.获取镜像 ## 使用下面命令获取最新版本的镜像,此时我的版本是1.3.0 ## 或者可以使用docker pull seataio/seata-server:latest获取最新的镜像 docke ...
- Spring + Atomikos 分布式事务实现方式
不同的数据库一定要分包建立 引用:http://blog.csdn.net/benluobobo/article/details/49818017 http://blog.csdn.net/yds49 ...
- MQ 分布式事务 -- 微服务应用
1.背景 友情链接:https://www.cnblogs.com/Agui520/p/11187972.html https://blog.csdn.net/fd2025/article/detai ...
- MQ关于实现最终一致性分布式事务原理解析
本文讲述阿里云官方文档中关于通过MQ实现分布式事务最终一致性原理 概念介绍 事务消息:消息队列 MQ 提供类似 X/Open XA 的分布式事务功能,通过消息队列 MQ 事务消息能达到分布式事务的最终 ...
- 对比7种分布式事务方案,还是偏爱阿里开源的Seata,真香!(原理+实战)
前言 这是<Spring Cloud 进阶>专栏的第六篇文章,往期文章如下: 五十五张图告诉你微服务的灵魂摆渡者Nacos究竟有多强? openFeign夺命连环9问,这谁受得了? 阿里面 ...
- 终于有人把“TCC分布式事务”实现原理讲明白了!
之前网上看到很多写分布式事务的文章,不过大多都是将分布式事务各种技术方案简单介绍一下.很多朋友看了还是不知道分布式事务到底怎么回事,在项目里到底如何使用. 所以这篇文章,就用大白话+手工绘图,并结合一 ...
- nodeEE双写与分布式事务要点一二
数据库与缓存双写问题 计算机领域任何一个问题都可以通过增加一个抽象"层"来解决. 业务中为了减少热点数据不必要的db查询,往往会增加一层缓存来解决I/O性能.可是I/O多了一层也就 ...
- 关于分布式事务,XA协议的学习笔记
XA分布式事务协议,包含二阶段提交(2PC),三阶段提交(3PC)两种实现. 1.二阶段提交方案:强一致性 事务的发起者称协调者,事务的执行者称参与者. 处理流程: 1.准备阶段 事务协调者,向所有事 ...
随机推荐
- Python代码混淆和加密技术
Python进行商业开发时, 需要有一定的安全意识, 为了不被轻易的逆向. 混淆和加密就有所必要了. 为了增加代码阅读的难度, 源代码的混淆非常必要, 一个在线的Python代码混淆网站. http: ...
- AcWing 849. Dijkstra求最短路 I 朴素 邻接矩阵 稠密图
//朴素Dijkstra 边权都是正数 稠密图:点和边差的比较多 #include<cstring> #include<iostream> #include<algori ...
- 查询 keystore文件的签名信息
需要安装jdk 在安装 jdk的/bin文件夹下 keytool -v -list -keystore [keystore文件的路径]
- 【 Struts2 过滤器】
LoginInterceptor package k.util; import com.opensymphony.xwork2.ActionInvocation; import com.opensym ...
- Go字符串
1. 字符串的声明是使用 package main import "fmt" func main() { /* Go中的字符串是一个字节的切片. 可以通过将其内容封装在“”中来创建 ...
- 简单记录搭建Harbor私服仓库
一.本机环境 ①系统镜像:CentOS7 ②Docker:Docker version 19.03.5 ③Docker-compose:docker-compose 二.Docker安装 参考官网安装 ...
- office自签名证书
在 Office安装目录,找到 SELFCERT 文件,双击打开填写名称,生成
- Spring-boot JDBC with multiple DataSources sample
Spring-Boot's auto-configurer seems good for simple applications. For example it automatically creat ...
- mysql测试点
前言 性能测试过程中,数据库相关指标的监控是不可忽视的,在这里我们就MySQL的监控配置及重点涉及性能的一些参数进行说明. 在笔者的日常性能测试过程中,重点关注了这些参数,但不代表仅仅只有这些参数对性 ...
- Spring基础篇——通过Java注解和XML配置装配bean(转载)
作者:陈本布衣 出处:http://www.cnblogs.com/chenbenbuyi 本文版权归作者和博客园共有,欢迎转载分享,但必须保留此段声明,且在文章页面明显位置给出原文链接,否则保留 ...