GitHub - 事务最终一致性 - MQ保证消息一致性

标签: | 发表时间:2019-07-23 08:59 | 作者:
出处:https://github.com

简介

使用rabbitMq来简单实现分布式事务的最终一致性 版本如下:
SpringCloud : Finchley.SR1
SpringBoot : 2.0.4.RELEASE
Gradle : 4.8

项目结构

目录 名称 访问地址
eureka 注册中心 http://127.0.0.1:8761
gateway 网关+路由 http://127.0.0.1:8769/order/buy 
http://127.0.0.1:8769/pay/pay
order 订单服务 http://127.0.0.1:8763/buy
pay 支付服务 http://127.0.0.1:8762/pay

启动顺序

rabbitMq -> 注册中心 -> 网关 -> 订单 -> 支付

整体流程

生产者的逻辑
1、订单入库
2、消息记录入库
3、发送消息(采用确认模式)
4、mq收到消息之后给生产端一个确认消息
5、生产端监听这个确认消息
6、根据监听结果操作消息表的状态
7、定时任务定时去操作消息状态为1未发送的记录,就是那些没有监听到结果的记录进行重新发送

消费者的逻辑
1、将收到消息的消息入库
2、处理消息失败消息记录的状态就为未处理
3、处理消息成功修改消息记录的状态为处理成功
4、收到相同的消息id的消息直接丢弃
5、定时任务去操作那些未处理,并且已经经过一段时间的消息
6、针对那些一直处理失败的,且很长一段时间都没办法处理成功的消息交由人工或者其他途径处理

数据库设计

数据库只是为了满足测试要求,不做实际用途

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for consumer_mq_tab
-- ----------------------------
DROP TABLE IF EXISTS `consumer_mq_tab`;
CREATE TABLE `consumer_mq_tab` (
  `messageId` varchar(255) NOT NULL,
  `messageContent` varchar(255) NOT NULL,
  `messageStatus` int(11) NOT NULL,
  `addTime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`messageId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- ----------------------------
-- Table structure for order_mq_tab
-- ----------------------------
DROP TABLE IF EXISTS `order_mq_tab`;
CREATE TABLE `order_mq_tab` (
  `messageId` varchar(255) NOT NULL,
  `messageContent` varchar(255) NOT NULL,
  `messageStatus` int(11) NOT NULL,
  `addTime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`messageId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- ----------------------------
-- Table structure for order_tab
-- ----------------------------
DROP TABLE IF EXISTS `order_tab`;
CREATE TABLE `order_tab` (
  `orderId` varchar(255) NOT NULL,
  `messageId` varchar(255) NOT NULL,
  `orderContent` varchar(255) NOT NULL,
  PRIMARY KEY (`orderId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

SET FOREIGN_KEY_CHECKS = 1;

具体完整项目说明讲解

https://www.cnblogs.com/linkstar/p/9784243.html

相关 [github 一致性 mq] 推荐:

GitHub - 事务最终一致性 - MQ保证消息一致性

- -
使用rabbitMq来简单实现分布式事务的最终一致性 版本如下:. 目录 名称 访问地址. gateway 网关+路由. rabbitMq -> 注册中心 -> 网关 -> 订单 -> 支付. 3、发送消息(采用确认模式). 4、mq收到消息之后给生产端一个确认消息. 5、生产端监听这个确认消息.

闲扯kafka mq

- - 开源软件 - ITeye博客
本文主要讲解关于kafka mq的设计思想及个人理解. 关于kafka的详细信息,大家可以参考官网的文献 http://kafka.apache.org/documentation.html这是一篇相当不错的文章,值得仔细研读. 第一个问题:消息队列(Message Queue)是干嘛用的. 首先,要对消息队列有一个基本的理解.

[MQ]关于ActiveMQ的配置

- - 企业架构 - ITeye博客
  目前常用的消息队列组建无非就是MSMQ和ActiveMQ,至于他们的异同,这里不想做过多的比较. 简单来说,MSMQ内置于微软操作系统之中,在部署上包含一个隐性条件:Server需要是微软操作系统. (对于这点我并去调研过MSMQ是否可以部署在非微软系统,比如:Linux,只是拍脑袋想了想,感觉上是不可以).

与MQ通讯的完整JAVA程序

- - 编程语言 - ITeye博客
        本文实例是基于 WebSphere MQ中将消息发送至远程队列的配置的基础上的,且如果要能正常运行并发送、接收消息,还需要在两个队列管理器(QM_ORANGE和QM_APPLE)上做如下配置或修改.         1.创建名称为DC.SVRCONN的服务器连接通道.         2.将队列管理器的通道认证记录设置为“已禁用”.

在Tomcat 6.0下用JNDI连接IBM MQ 6.0的配置方法

- - 行业应用 - ITeye博客
假设在IBM MQ中定义的队列管理器的名为QueueManager, 端口1414,CCSID 437 ,创建名为LQ1,LQ2的队列分别用于发送和接收消息, 服务器连接通道名为SVRCONN. 确保在项目的Classpath中导入了以下的jar包:. 如果需使用spring的JmsTemplate方式来读写MQ,还需要导入.

消息队列mq的3个使用场景

- - 互联网 - ITeye博客
2、tomcat controller取到请求后向rocketmq 发送一个msg,将msg id返回给app,同时在redis里缓存msg状态为init(设置定时时间,时间到后清除). 3、client(app/h5/小程序) 通过msg id,定时向server获取msg处理状态. (init时 画圈,没有时返回繁忙,fail时返回处理失败).

使用MQ的时候,怎么确保消息100%不丢失?

- - 掘金后端本月最热
面试官在面试候选人时,如果发现候选人的简历中写了在项目中使用了 MQ 技术(如 Kafka、RabbitMQ、RocketMQ),基本都会抛出一个问题: 在使用 MQ 的时候,怎么确保消息 100% 不丢失. 这个问题在实际工作中很常见,既能考察候选者对于 MQ 中间件技术的掌握程度,又能很好地区分候选人的能力水平.

Home · JohnLangford/vowpal_wabbit Wiki · GitHub

- -
There are two ways to have a fast learning algorithm: (a) start with a slow algorithm and speed it up, or (b) build an intrinsically fast learning algorithm.

GitHub - jgraph/drawio: Source to www.draw.io

- -
draw.io supports IE 11, Chrome 32+, Firefox 38+, Safari 9.1.x, 10.1.x and 11.0.x, Opera 20+, Native Android browser 5.1.x+, the default browser in the current and previous major iOS versions (e.g.

不恰当使用线程池处理 MQ 消息引起的故障

- - 码蜂笔记
业务部门反应网站访问特别慢,负责运维监控的同事说MQ消息队列积压了,中间件的说应用服务器内存占用很高,GC 一直回收不了内存,GC 线程占了近 100% 的 CPU,其他的基本上都在等待,数据库很正常,完全没压力. 没啥办法,线程、堆 dump 出来后,重启吧,然后应用又正常了. 这种故障之前其实也碰到过了,分析了当时 dump 出来的堆后发现,处理 MQ 消息的线程池的队列长度达百万级别,占用了超过 1.3G 内存,这些内存都是没法回收的.