transaction-mq: 微服务架构中基于MQ的分布式事务解决方案

# transaction-mq

**项目介绍** 
基于SptringBoot、redis、mybatis
SpringCloud-eureka 、SpringCloud-feign
ActiveMQ
Redisson
实现数据最终一致的分布式事务解决方案
整个方案包括业务发起系统，可靠性消息服务，消息发送系统，消息队列（MQ）, 业务接收系统
整体思路：
1）发送系统在完成自身业务后调用可靠性消息服务发起消息；
2）可靠性消息服务负责消息存储、提供消息维护服务（消息状态、发送次数，死亡次数维护等）；
3）消息发送系统读取未消费的消息，向MQ发送消息，发送成功后修改消息发送次数以及最近发送时间；
4）消息队列（MQ）天然异步解耦的方式作为消息通道连接业务发起系统和业务接收系统；
4)业务接收系统从MQ中消费业务消息，完成最终一致性的分布式事务操作。

**软件架构说明** 
transaction-mq-common 公共组件
spring-eureka 服务注册中心（服务注册与发现）
feign 声明式服务调用
send-server 业务发起方系统
1. 发起修改自身业务的操作，如果修改成功则调用可靠性消息服务的消息发送接口发送业务修改操作；
2. 如果修改失败则进行事务回滚，不发送消息给可靠性消息服务
3. 由此保证数据在业务发起系统中的完整性和一致行。

transaction-mq-service 可靠性消息服务
1. 在可靠性消息服务所在数据库创建一张消息表，主要包含发送消息的系统、消费系统、队列名称、消息内容、消息状态（等待消费、已消费、已死亡）、最近发送消息时间、消费时间、重复发送消息次数，死亡次数（默认为发送10次还没被消费则标记死亡）；
2. 接收消息发送系统发送的业务请求数据，首先将此请求数据作为消息内容存储至以上消息表，将消息状态设置为待消费；
3. 提供查询最早未被消费的消息、确认消息被消费、确认消息死亡、累加发送次数、重新发送当前已死亡的消息等接口服务。

transaction-mq-clinet Feign客户端
作为transaction-mq-service 服务的客户端，对外提供消息发送，消息管理一系列接口服务。

transaction-mq-tash 消息发送系统
1. 基于分布式锁Redisson、线程池、信号量Semaphore限流技术读取指定条数内（可灵活设置：比如5000条）的待消费消息；
2. 读取后首先进行消息的死亡判断，如果发送次数已经超过设定的死亡次数，就调用确认消息死亡接口把消息设置成死亡消息，此时通过调用可靠性消息服务的重新发送当前已死亡的消息接口进行重发，也可以人工介入，对死亡的消息进行重发；
3. 然后进行发送时间的判断，没有超过指定时间（可灵活设置：比如1分钟）内的消息不进行重新发送，如果在指定时间外（1分钟外）就向MQ中发送消息同时调用累加发送次数服务更新这条消息的发送时间和发送次数。
4. 保证系统在高并发的分布式环境下的高吞吐量和高可用性；

substitution-server 业务接收方系统
1. 作为消息的消费方消费MQ中的消息，当消费成功后，通过调用确认消息被消费接口告诉可靠性消息服务该消息已经正常消费；
2. 如果消费失败，可以不用通知可靠性消息服务，负责发送消息的消息发送系统会对没有正常消费的消息进行重新发送；
3. 由此保障分布式环境下数据的最终一致性。

#### 安装教程

1.  安装配置activemq
2.  安装配置redis
3.  执行SQL初始化脚本

#### 使用说明

1. 先启动redis、activemq、eureka 服务
2. 启动send-server、transaction-mq-service、transaction-mq-tash、substitution-server
3. 调用send-server restfull API 发起业务请求
4. 查看消费方substitution-server 对应业务数据的变化实现数据最终一致效果。

**架构图**

![输入图片说明](https://images.gitee.com/uploads/images/2019/1207/135527_f598b400_764599.png "分布式事务解决方案.png")

喝呵何合盒/transaction-mq

简介

发行版

贡献者

近期动态

喝呵何合盒/transaction-mq .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

喝呵何合盒/transaction-mq