浩瀚宇宙的一粒尘埃

业务团队反馈使用我提供的RocketMQ集群，上游生产的消息，部分消息，消费程序需要等1分钟，甚至几分钟后，才能收到。

console报错，无法连接该节点，经排查，该节点为slave，把该节点杀掉，还是继续报错，重启之后，报错的端口变成11911。

为了支持长远的云原生发展，RocketMQ引入了一个全新的模块：Proxy，官方对RocketMQ客户端提供了独立的开源项目：https://github.com/apache/rocketmq-clients，如果要使用这个新的客户端，必须要使用Proxy作为endpoint。

搭建一个3主3从的集群，RocketMQ版本为5.1.0；采用交叉部署（避免两台机器互为主从），节省机器资源；3个nameserver、1个exporter、1个dashboard；支持自动故障恢复，controller采用内嵌在nameserver中的方式部署；异步刷盘；主从切换时，不能丢消息

基于5.1.0版本，做定时消息的功能测试和简单的性能测试，也有一些有用的Tips

RocketMQ对任意时刻延迟消息的支持，是基于主流的方案——时间轮做的，使用需要升级至5.X版本，客户端也需要使用最新的rocketmq-client-java

checkMsgSendRT是以生产者的角度，检查发送消息的延迟情况，而clusterRT更关注的是集群中每组主从节点的延迟情况，后面可以根据每个命令的参数来做了解。

这是记录一次辛酸的Linux + Python + RocketMQ使用历程，需求背景是需要验证线上一个RocketMQ服务和里面的Topic，如果使用Java，还得打包，上传，太麻烦，使用脚本语言会方便很多，遇到的问题比较多，但是又不想省略其中的过程，就全记录下来了。

文章目录问题详情问题定位问题解决问题详情业务团队反馈使用RocketMQ时，消费失败，报如下的错误：错误1:java.io.FileNotFoundException: C:\Users\zhangzhen16\.rocketmq_offsets\10.201.241.170@172.24.140.45:9876;172.24.130.73:9876@12188\sas_rule_event_consumer\offsets.json.tmp (文件名、目录名或卷标语法不正确。) at java

文章目录安装AlertManager编写告警规则文件配置PrometheusWebhook接口安装AlertManager下载地址：https://prometheus.io/download/解压：tar -zxvf alertmanager-0.23.0.linux.amd64.tar.gz修改alertmanager.yml配置文件，添加webhookroute: group_wait: 30s group_interval: 5m repeat_interval: 1h

由异常的字面信息，怀疑是并发过高，导致服务端负载太大，导致请求处理不过来了，但是细想，RocketMQ的TPS单机是几万，集群是3主6从，也就是TPS可以达到10w左右，不可能业务团队可以承受的TPS，到RocketMQ端处理不过来，所以问题没那么简单，于是打开源码看一下问题出现的原因。也就是说，确实是服务端处理不过来了，有的文章说需要把超时时间设置长一点，但是这治标不治本，并且官方的压测代码，用的都是默认的配置，所以问题并不是修改配置那么简单，还需要进一步探究。难道真的被打满了吗？

前言研究RocketMQ的同学都知道，RocketMQ的生态目前并不是很完善，包括官方的文档资料也有限，官方的Console存在一些Bug，页面的样式有的也有问题，但是正是由于这些原因，我们针对RocketMQ能做的事有很多，不像Kafka，生态已经很完善，一些企业也对Kafka做了开源的产品，最近开始做基于K8S的RocketMQ管理控制台，需要对每个集群有完善的监控告警，接下来就简单说明一下做RocketMQ的监控有哪些步骤。部署rocketmq-exporter以下操作基于Linux系统。首先

文章目录表达式过滤TAG使用原理SQL92使用原理类过滤使用原理RocketMQ支持表达式过滤与类过滤两种模式 。表达式过滤其中表达式模式分为 TAG和SQL92表达式两种。TAG顾名思义，TAG 模式就是简单地为消息定义标签，根据消息的标签进行匹配。使用1、在消息发送时，我们可以为每一条消息设置一个TAG标签，消息消费者订阅自己感兴趣的TAG, 一般使用的场景是，对于同一类的功能（如：数据同步）创建一个主题，但对于该主题下的数据，可能不同的系统关心的数据不一样，基础数据各个系统都需要同步，设

测试信息集群信息：集群1：版本4.7.1，3m-6s，单Broker8G内存，异步复制，异步刷盘，开启了消息追踪集群2：所有配置一样，不同点是未开启消息追踪功能备注：集群1的机器性能好，配置为104c、700g；集群2为8c、32g，所以理论上配置相同的情况下，集群2的性能要比测试的结果略高测试维度：服务端开启消息追踪功能，客户端使用和不使用消息追踪的性能差别服务端开启和不开启消息追踪功能，对客户端的性能影响测试参数：线程数：128消息大小：128byte集群开启消息追踪客户端使

背景业务团队使用的集群是我们中间件组搭建的，使用的客户端是微服务组基于原生的客户端封装的xcloud-rocketmq业务团队在项目上线之后，反馈线上程序一直报错：问题分析1、看到业务团队这个表述，让我理解为线上集群存在问题，业务方topic在console创建成功了，但是发送消息时失败了，为了确保线上集群没问题，我先创建了一个测试的topic，写一个Java客户端进行发送消息，发现一切正常；2、怀疑是客户端的问题，因为我使用的是原生的生产者，业务方使用的是微服务组封装的xcloud

集群信息版本：4.7.1规模：3主6从刷盘方式：异步刷盘主从复制：异步复制压测参数工具：官方benchmark脚本线程数：200消息大小：128byte压测结果集群TPS最高能到10W，平稳后集群TPS有7W+，单机有2W+CPU消耗情况BrokerBroker的CPU消耗大部分时间平稳保持在4c以下，时偶尔会升到10c左右，升高时TPS会下降，猜测是因为GC导致NameServernameserver对CPU几乎无消耗...

最近在做性能测试的时候发现，当集群开启了DLedger高可用之后，性能很差，详细过程如下：集群信息集群1：版本4.7.1，3Master，每个Master两个Slave，单Broker8G内存，异步复制，异步刷盘集群2：所有配置一样，不同点是开启了DLedger压测结果使用相同参数进行压测：线程数：128，消息大小：128byte，压测结果对比如下：集群1:集群2:可以看到，开启DLedger之后，性能骤降30倍，TPS只有3000+，有点懵，于是怀疑是否是集群2的配置错了，检查了一下集

文章目录背景需求构建源码修改源码打开页面按钮修改弹出框修改js传参修改接口方法编写告警逻辑测试背景​ 业务团队希望对消费者的健康状态有感知，在消费发生延迟时能收到告警通知，可以通过RocketMQ提供的的SDK：MQAdminExt写一个定时的程序，扫描消费者的状态，并通过比较配置的阈值，来判断是否需要发告警通知，还有一种方法就是直接使用RocketMQ官方提供的console来做，只不过该功能需要动手打开。需求​ 不同的消费组可以配置不同的告警规则，并且可以配置邮箱，进行邮件发送，邮件内容包含

文章目录测试ProducerConsumerPUSH模式PULL模式总结遇到的问题测试当前集群状态：3主6从，启动DLedger测试方案：运行客户端Producer和Consumer程序稳定运行后，将broker的Leader通过脚本停止观察客户端程序日志为了方便日志查看，生产者速率为每秒100条，单线程客户端平稳运行之后，停掉指定broker的Leader，观察客户端程序日志Producer有两种情况：1、如果挂掉的broker当前无客户端在提交消息，则无影响可以看到，

文章目录DLedger配置介绍新建DLedger集群机器规划BrokernameserverconsoleBroker配置broker-abroker-a-s1broker-a-s2broker-bbroker-b-s1broker-b-s2broker-cbroker-c-s1broker-c-s2验证旧集群升级杀掉旧的 Broker检查旧的 Commitlog修改配置重新启动 BrokerTips本文主要演示如何搭建一个多主多从的自动容灾切换的RocketMQ集群，以及如何把现有普通的Master/S

介绍什么是ACLRocketMQ在4.4.0版本开始支持ACL。ACL是Access Control List的简称，俗称访问控制列表。访问控制，基本上会涉及到用户、资源、权限、角色等概念，那在RocketMQ中上述会对应哪些对象呢？用户：用户是访问控制的基础要素，也不难理解，RocketMQ ACL必然也会引入用户的概念，即支持用户名、密码资源：资源，需要保护的对象，在RocketMQ中，消息发送涉及的Topic、消息消费涉及的消费组，应该进行保护，故可以抽象成资源权限：针对资源，能进行的操作

文章目录背景准备工作下载二进制包NameServerBroker脚本文件NameServerBroker如何使用上传文件部署背景​ 最近公司很多业务需要使用RocketMQ，阿里的云服务昂贵且运维不及时，所以业务团队找到我们部门，由我们部门负责RocketMQ集群的技术支持，每个业务都需要使用独立的集群，而且开发、测试、线上三个环境都需要搭建，靠“人工智能”确实有点太重复造轮子了，K8S环境的话，Operator我们还没开始弄成熟，着急上线的话，也担心出问题，于是决定写个自动部署RocketMQ集群的

​ [TOC]RocketMQ的Broker分为Master和Slave两个角色，为了保证高可用性(HA)， Master角色的机器接收到消息后，要把内容同步到Slave机器上，这样一旦Master宕机，Slave机器依然可以提供服务。 下面介绍Master和Slave角色机器间同步功能实现的源码。同步元数据​ Slave需要和Master同步的不只是消息本身，一些元数据信息也需要同步，比如TopicConfig信息、ConsumerOffset信息、DelayOffset和Subscription

内容有点多，左侧有菜单。

下载二进制包下载链接：RocketMQ官网注：二进制包是编译好的，拿来可以直接用，如果不需要定制化，改动源码，可选择二进制包机器准备准备三台机器，每台机器需要安装好jdk，1.8以上版本；集群使用交叉部署：三台机器，每台各自装一个nameserver，三个broker：一个master，两个其他master的slave；目录结构：机器1：namesever-1、master-a、b-slave1、c-slave1机器2：namesever-2、master-b、a-slave1、c-sl