Apache RocketMQ

历史原因，当前有一个服务专门用于处理mq消息，mq使用的阿里云rocketmq，sdk版本1.2.6（2016年）。 随着业务的发展，该应用上的consumer越来越多，接近200+，导致该应用所在的ecs长时间load高，频繁报警。 现象分析 该应用所在的ecs服务器load长期飙高（该ecs上只有一个服务），但cpu、io、内存等资源利用率较低，系统负载参考下图： ECS配置：4核8G 物理cpu个数=4 单个物理CPU中核（core）的个数=1 单核多处理器 在系统负荷方面，多核CPU与多CPU效果类似，考虑系统负荷的时候，把系统负荷除以总的核心数，只要每个核心的负荷不超过1.0，就表明正常运行。 通常，n核cpu时， load<n ，系统负载都属于正常情况。 套用以上规则： 先观察load_15m和load_5m，load基本保持在3-5之间，说明系统中长期负载保持在一个较高的量级。 再观察load_1m可以看出，波动很大，并且很多时间段内远大于cpu核心数。 短期内繁忙，中长期内紧张，很可能是一个拥塞的开始。 原因定位 排查导致load高的原因 tips：系统load高，不代表cpu资源不足。Load高只是代表需要运行的队列累计过多。但队列中的任务实际可能是耗cpu的，也可能是耗i/0及其他因素的 图中load_15,load_5,load_1均大于核心数4，超负荷运行

文章目录 7.1 MQ简介 7.1.1 什么是MQ 7.1.2 MQ的应用场景 7.1.2.1 异步解耦 7.1.2.2 流量削峰 7.1.3 常见的MQ产品 7.2 RocketMQ入门 7.2.1 RocketMQ环境搭建 7.2.1.1 环境准备 7.2.1.2 安装RocketMQ 7.2.1.3 启动RocketMQ 7.2.1.4 测试RocketMQ 7.2.1.5 关闭RocketMQ 7.2.2 RocketMQ的架构及概念 7.2.3 RocketMQ控制台安装 7.3 消息发送和接收演示 7.3.1 发送消息 7.3.2 接收消息 7.4 案例 7.4.1 订单微服务发送消息 7.4.2 用户微服务订阅消息 7.5 发送不同类型的消息 7.5.1 普通消息 7.5.2 顺序消息 7.5.3 事务消息 7.6 消息消费要注意的细节 7.1 MQ简介 7.1.1 什么是MQ MQ（Message Queue）是一种跨进程的通信机制，用于传递消息。通俗点说，就是一个先进先出的数据结构。 7.1.2 MQ的应用场景 7.1.2.1 异步解耦 最常见的一个场景是用户注册后，需要发送注册邮件和短信通知，以告知用户注册成功。传统的做法如下： 此架构下注册、邮件、短信三个任务全部完成后，才返回注册结果到客户端，用户才能使用账号登录。但是对于用户来说

RocketMQ控制台的安装 控制台目前获取方式有如下两种： 1.第三方网站去下载现成的，比如csdn等。 2.官方源码包自己编译而成，官方没有现成的。 我们这里当然采取官方方式。 1、rocketmq-console安装 1.1源码下载： https://codeload.github.com/apache/rocketmq-externals/zip/master 1.2修改配置文件：rocketmq-console\src\main\resources\application.properties 1.3配置连接地址：默认是空的 1.4编译打包：mvn clean package -DskipTests 启动 java -jar rocketmq-console-ng-2.0.0.jar 日志如下： [2020-08-11 02:40:30.086] INFO closeChannel: close the connection to remote address[192.168.111.129:10911] result: true [2020-08-11 02:40:30.087] INFO closeChannel: close the connection to remote address[192.168.111.129:9876] result: true 2

折腾了好长时间才写这篇文章，顺序消费，看上去挺好理解的，就是消费的时候按照队列中的顺序一个一个消费；而并发消费，则是消费者同时从队列中取消息，同时消费，没有先后顺序。RocketMQ也有这两种方式的实现，但是在实践的过程中，就是不能顺序消费，好不容易能够实现顺序消费了，发现采用并发消费的方式，消费的结果也是顺序的，顿时就蒙圈了，到底怎么回事？哪里出了问题？百思不得其解。 经过多次调试，查看资料，debug跟踪程序，最后终于搞清楚了，但是又不知道怎么去写这篇文章，是按部就班的讲原理，讲如何配置到最后实现，还是按照我的调试过程去写呢？我觉得还是按照我的调试过程去写这篇文章吧，因为我的调成过程应该和大多数人的理解思路是一致的，大家也更容易重视。 环境回顾 我们先来回顾一下前面搭建的RocketMQ的环境，这对于我们理解RocketMQ的顺序消费是至关重要的。我们的RocketMQ环境是一个两主两从的异步集群，其中有两个broker，broker-a和broker-b，另外，我们创建了两个Topic，“cluster-topic”，这个Topic我们在创建的时候指定的是集群，也就是说我们发送消息的时候，如果Topic指定为“cluster-topic”，那么这个消息应该在broker-a和broker-b之间负载；另外创建的一个Topic是“broker-a-topic”

本文源码： GitHub·点这里 || GitEE·点这里 一、JTA组件简介 1、JTA基本概念 JTA即Java-Transaction-API，JTA允许应用程序执行分布式事务处理，即在两个或多个网络计算机资源上访问并且更新数据。JDBC驱动程序对JTA的支持极大地增强了数据访问能力。 XA协议是数据库层面的一套分布式事务管理的规范,JTA是XA协议在Java中的实现,多个数据库或是消息厂商实现JTA接口,开发人员只需要调用SpringJTA接口即可实现JTA事务管理功能。 JTA事务比JDBC事务更强大。一个JTA事务可以有多个参与者，而一个JDBC事务则被限定在一个单一的数据库连接。下列任一个Java平台的组件都可以参与到一个JTA事务中 2、分布式事务 分布式事务（DistributedTransaction）包括事务管理器（TransactionManager）和一个或多个支持 XA 协议的资源管理器 ( Resource Manager )。 资源管理器是任意类型的持久化数据存储容器，例如在开发中常用的关系型数据库：MySQL，Oracle等，消息中间件RocketMQ、RabbitMQ等。 事务管理器提供事务声明，事务资源管理，同步，事务上下文传播等功能，并且负责着所有事务参与单元者的相互通讯的责任。JTA规范定义了事务管理器与其他事务参与者交互的接口

目录 SpringBoot如何优雅的使用RocketMQ 什么是RocketMQ？ RocketMQ环境安装 SpringBoot环境中使用RocketMQ SpringBoot如何优雅的使用RocketMQ MQ，是一种跨进程的通信机制，用于上下游传递消息。在传统的互联网架构中通常使用MQ来对上下游来做解耦合。 举例：当A系统对B系统进行消息通讯，如A系统发布一条系统公告，B系统可以订阅该频道进行系统公告同步，整个过程中A系统并不关系B系统会不会同步，由订阅该频道的系统自行处理。 什么是RocketMQ？ 官方说明: 随着使用越来越多的队列和虚拟主题，ActiveMQ IO模块遇到了瓶颈。我们尽力通过节流，断路器或降级来解决此问题，但效果不佳。因此，我们那时开始关注流行的消息传递解决方案Kafka。不幸的是，Kafka不能满足我们的要求，特别是在低延迟和高可靠性方面。 看到这里可以很清楚的知道RcoketMQ 是一款低延迟、高可靠、可伸缩、易于使用的消息中间件。 具有以下特性： 支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型 能够保证严格的消息顺序，在一个队列中可靠的先进先出（FIFO）和严格的顺序传递 提供丰富的消息拉取模式，支持拉（pull）和推（push）两种消息模式 单一队列百万消息的堆积能力，亿级消息堆积能力 支持多种消息协议，如 JMS、MQTT 等

序 本文主要研究一下rocketmq-client-go的api.go Producer rocketmq-client-go-v2.0.0/api.go type Producer interface { Start() error Shutdown() error SendSync(ctx context.Context, mq ...*primitive.Message) (*primitive.SendResult, error) SendAsync(ctx context.Context, mq func(ctx context.Context, result *primitive.SendResult, err error), msg ...*primitive.Message) error SendOneWay(ctx context.Context, mq ...*primitive.Message) error } func NewProducer(opts ...producer.Option) (Producer, error) { return producer.NewDefaultProducer(opts...) } Producer定义了Start、Shutdown、SendSync、SendAsync、SendOneWay方法

1. 简介 1. RocketMQ 是什么？ RocketMQ 是由阿里捐赠给 Apache 的一款分布式、队列模型的开源消息中间件，经历了淘宝双十一的洗礼。 2. RocketMQ 的特性 原生分布式 两种消息拉取 严格消息顺序 特有的分布式协调器 亿级消息堆积 组(Group) 2. RocketMQ 基本概念 概念 描述 Producer 消息生产者，负责生产消息，一般由业务系统负责产生消息。 Consumer 消息消费者，负责消费消息，一般是后台系统负责异步消费。 Push Consumer 封装消息拉取，消费进程和内部。 Pull Consumer 主动拉取消息，应用的消费进程进行初始化。 Producer Group 一类 Producer 的集合名称，这类 Producer 通常发送一类消息，且发送逻辑一致。 Consumer Group 一类 Consumer 的集合名称，这类 Consumer 通常消费一类消息，且消费逻辑一致。 Broker 消息中转角色，负责存储消息，转发消息，这里就是 RocketMQ Server。 Topic 消息的主题，用于定义并在服务端配置，消费者可以按照主题进行订阅，也就是消息分类，通常一个系统一个 Topic。 Message 在生产者、消费者、服务器之间传递的消息，一个 message 必须属于一个 Topic Namesrv

1. 为什么要用 MQ 消息队列是一种“先进先出”的数据结构 其应用场景主要包含以下3个方面 应用解耦 系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。 使用消息队列解耦合，系统的耦合性就会提高了。比如物流系统发生故障，需要几分钟才能来修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统回复后，补充处理存在消息队列中的订单消息即可，终端系统感知不到物流系统发生过几分钟故障。 流量削峰 应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理，这样可以大大提到系统的稳定性和用户体验。 一般情况，为了保证系统的稳定性，如果系统负载超过阈值，就会阻止用户请求，这会影响用户体验，而如果使用消息队列将请求缓存起来，等待系统处理完毕后通知用户下单完毕，这样总不能下单体验要好。 处于经济考量目的： 业务系统正常时段的QPS如果是1000，流量最高峰是10000，为了应对流量高峰配置高性能的服务器显然不划算，这时可以使用消息队列对峰值流量削峰 数据分发 通过消息队列可以让数据在多个系统更加之间进行流通。数据的产生方不需要关心谁来使用数据

在实际开发中，经常需要排查一条消息是否成功发送到底层MQ中，或者查看MQ中消息的内容，以及如何将消息发送给指定的/所有的消费者组重新消费。本文对RocketMQ提供到的查询机制和背后原理进行深入的介绍。文章主要包括4个部分： 消息查询介绍：介绍消息查询中使用到的Message Key 、Unique Key、Message Id 的区别 消息查询工具：分别介绍命令行工具、管理平台、客户端API这三种工具的详细用法，以及如何让消费者重新消费特定的消息。 核心实现原理：介绍Message Key & Unique Key与Message Id的实现机制上区别，Unique Key在Exactly Once语义下的作用，以及为什么Message Id查询效率更高。 索引机制：介绍Message Key & Unique Key底层使用的哈希索引机制 1 消息查询介绍 RocketMQ提供了3种消息查询方式： 按照Message Key 查询：消息的key是业务开发同学在发送消息之前自行指定的，通常会把具有业务含义，区分度高的字段作为消息的key，如用户id，订单id等。 按照Unique Key查询：除了业务开发同学明确的指定消息中的key，RocketMQ生产者客户端在发送发送消息之前，会自动生成一个UNIQ_KEY，设置到消息的属性中，从逻辑上唯一代表一条消息。 按照Message