RocketMQ配置与安装以常见安装错误梳理

本文详细介绍了Apache RocketMQ的下载、环境配置、启动步骤以及解决启动过程中遇到的JDK环境变量问题。此外,还提及了新版本RocketMQ可视化工具的下载、配置和运行方法,包括修改application.yml文件和使用Maven构建jar包。最后,文章提供了部分参考资料,感谢原作者的分享。

下载
http://rocketmq.apache.org/release_notes/release-notes-4.3.0/

引用别人的博客的图片

配置:(*注意:rocketmq存放路径最好别有空格,否则配置容易出错)
配置环境变量:ROCKETMQ_HOME
变量值:MQ解压路径\MQ文件夹名(这个路径不能有空格,否则会报错)
在这里插入图片描述

在path下面配置
在这里插入图片描述

启动NAMESERVER.cmd

进入到安装目录的bin目录下,执行

start mqnamesrv.cmd

在这里插入图片描述

等待几秒钟会出现以下结果:
在这里插入图片描述

第一个终端窗口不要关闭

启动BROKER.cmd
在同样bin目录下的cmd窗口中输入

start mqbroker.cmd -n 127.0.0.1:9876 autoCreateTopicEnable=true

新弹出的终端窗口出现如下报错:

启动之后出现了错误: 找不到或无法加载主类 Files\Java\jdk1.8.0_311\lib\dt.jar;C:\Program

原因:

  1. JDK的环境变量配置出现错误,根据报错的路径查看环境变量是否出错。
  2. 进入安装RocketMQ的bin目录中编辑runbroker.cmd文件
    (花了快两小时反复检查和测试,人都麻了)在这里插入图片描述
    保存后再次运行上述代码
    在这里插入图片描述

安装可视化工具
之前的大多数教程中的connet-console文件已经被删除。

新的可视化工具可以使用以下仓库中的文件。
https://github.com/apache/rocketmq-dashboard
在这里插入图片描述

下载解压到任意文件夹之后,进入到application.yml文件进行相应的配置

	 将server下的port选定到PC中未被占用的端口(文件路径查看左侧目录)

在这里插入图片描述

打开终端进入rocketmq-dash的安装文件目录下,执行:
mvn clean package -Dmaven.test.skip=true
转换成jar包,等待漫长时间。
在这里插入图片描述
出现BUILD SUCCESS则为成功。

可在安装rocket-dash的文件目录下找到生成的jar包(图片目录下倒数第二个文件)
在这里插入图片描述
进入target后执行:java -jar rocketmq-dashboard-1.0.1-SNAPSHOT.jar,这里是在启动jar工程。

启动完毕后,在浏览器输入:http://localhost:xxxx/ (在application.yml中设置的server:port)
在这里插入图片描述

为节省时间,本文大部分图片和内容源自darendu的优快云博客,感谢!
作者:darendu

<think>嗯,用户让我排查RocketMQ消费者无法监听到消息的问题。这个问题很典型,需要系统性地梳理可能的原因和解决方案。 首先想到的是网络连通性问题,这是最基础的排查点。消费者和Broker之间的网络不通会导致消息无法接收。用户需要检查消费者Broker之间的网络是否可达,包括端口是否开放。特别是9876端口(NameServer)和10911端口(Broker)是否被防火墙拦截。可以通过telnet命令测试端口连通性,或者使用RocketMQ自带的admin工具检查连接状态。 然后是订阅关系匹配问题。消费者组订阅的Topic和Tag必须生产者发送的消息完全一致,包括大小写。常见错误是消费者订阅了Topic_A而生产者发送到Topic_B,或者Tag表达式不匹配。用户需要核对消费者代码中的subscribe()方法参数,特别是当使用SQL92过滤时更要注意语法正确性。 消费者组配置也是关键点。同一个消费者组内的所有实例必须保持订阅关系完全一致,否则会出现消息分配混乱。另外要检查消费者是否配置了广播模式导致消息重复消费的错觉。查看Broker的订阅关系配置表可以验证这一点。 消费位点异常容易被忽视。如果消费位点被重置到未来时间点,或者积压量过大导致位点过期,都会造成"无消息"的假象。用户需要检查Broker的消费进度,确认位点是否正常。使用resetOffset命令重置位点可能解决这个问题。 客户端状态异常需要检查消费者实例是否正常运行。查看日志中是否有重平衡错误、线程阻塞等情况。特别是当内存打满时,消费者可能保持心跳但实际已无法处理消息。升级实例资源或重启消费者往往能解决这类问题。 消息轨迹功能是很好的排查工具。通过控制台查看消息是否正常存储,以及消费者是否有拉取记录。如果没有拉取记录,说明问题出在消费者端;如果有拉取但未消费,则可能是处理逻辑问题。 最后是客户端兼容性问题。不同版本的RocketMQ客户端可能存在协议差异,建议保持服务端和客户端版本一致。同时检查依赖冲突,特别是Netty等核心库的版本冲突可能导致网络层异常。 在排查步骤上,建议用户从简单到复杂:先验证网络和端口,再检查订阅配置,然后观察消费位点,最后分析客户端日志。使用控制台的消息轨迹功能可以快速定位问题环节。</think>以下是RocketMQ消费者无法监听到消息的常见原因及系统化排查解决方案: --- ### **一、网络连接问题** 1. **Broker连接异常** - 检查消费者是否连接到正确的NameServer地址(`namesrvAddr`配置- 验证网络连通性: ```bash telnet <NameServer_IP> 9876 # 默认NameServer端口 telnet <Broker_IP> 10911 # 默认Broker端口 ``` - **解决**:修复网络策略或更正配置(引用[2]消息传输可靠性机制)。 2. **消费者组未注册** - 通过命令检查消费者组是否在线: ```bash mqadmin consumerConnection -g <ConsumerGroup> -n <NameServer_IP>:9876 ``` - **解决**:重启消费者实例或检查客户端启动日志。 --- ### **二、订阅关系不匹配** 1. **Topic/Tag订阅错误** - 生产者发送的Topic必须消费者订阅的Topic**完全一致**(大小写敏感) - 检查Tag过滤表达式(如`*`表示全部,`tagA || tagB`表示逻辑或) - **解决**:核对生产者消费者的Topic/Tag配置。 2. **订阅关系冲突** - 同一消费者组内所有实例的**订阅关系必须完全相同**(Topic/Tag/过滤模式) - **解决**:通过命令检查订阅一致性: ```bash mqadmin querySubByGroup -g <ConsumerGroup> -n <NameServer_IP>:9876 ``` --- ### **三、消费位点异常** 1. **位点进度滞后或重置** - 若消费位点被重置到未来时间(如手动修改偏移量),新消息无法触发消费 - **解决**:使用命令重置位点: ```bash mqadmin resetOffsetByTime -g <ConsumerGroup> -t <Topic> -s -1 -n <NameServer_IP>:9876 # -1表示重置为最新位点 ``` 2. **消息积压导致位点过期** - 积压消息超过保留时间(默认72小时)会被清理(引用[1]) - **解决**:扩容消费者实例或优化消费逻辑(引用[4]资源不足案例)。 --- ### **四、客户端问题** 1. **消费者线程阻塞** - 检查消费逻辑是否卡死(如死锁、长耗时操作) - **解决**:添加超时控制或异步处理消息。 2. **资源耗尽** - 监控CPU/内存:实例资源不足会导致进程假死(引用[4]内存打满案例) - **解决**:升级实例配置或优化资源使用。 3. **客户端版本兼容性** - Broker客户端版本差异可能导致协议不兼容 - **解决**:升级至官方推荐匹配版本。 --- ### **五、Broker端问题** 1. **消息未持久化** - 生产者发送失败或Broker刷盘异常导致消息丢失(引用[2]持久化机制) - **解决**: - 生产者启用事务消息 - 检查Broker磁盘空间及`flushDiskType`配置。 2. **主从同步延迟** - 若消费者配置`consumeFromWhere=CONSUME_FROM_LAST`且主从延迟,可能漏读消息 - **解决**:临时切换为`CONSUME_FROM_FIRST`或修复主从同步。 --- ### **六、排查工具** 1. **消息轨迹追踪** ```bash mqadmin queryMsgByKey -t <Topic> -k <MsgKey> -n <NameServer_IP>:9876 ``` - 确认消息是否成功存储到Broker。 2. **消费状态监控** ```bash mqadmin consumerProgress -g <ConsumerGroup> -n <NameServer_IP>:9876 ``` - 查看`DIFF`列(积压量)和`LAST_CONSUMED_TIMESTAMP`(最后消费时间)。 --- ### **总结排查流程** ```mermaid graph TD A[消费者无消息] --> B{网络连通性} B -->|正常| C{订阅关系匹配} B -->|异常| NET[修复网络/端口] C -->|匹配| D{消费位点状态} C -->|不匹配| SUB[修正Topic/Tag] D -->|正常| E{客户端资源} D -->|异常| OFFSET[重置位点] E -->|充足| F[检查Broker消息] E -->|不足| RES[扩容实例] F -->|有消息| G[分析消费逻辑] F -->|无消息| H[排查生产者] ``` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值