RocketMQ 常见异常处理

最新推荐文章于 2025-06-07 22:17:31 发布
转载 最新推荐文章于 2025-06-07 22:17:31 发布 · 8.3k 阅读 · 0

本文详细解析了RocketMQ中常见的Norouteinfoofthistopic及RemotingTooMuchRequestException异常，探讨了异常产生的原因，包括Broker配置、NameServer连接与防火墙设置，并提供了详细的排查与解决方案。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

MQClientException: No route info of this topic, TopicTest1

异常说明

  • 在客户端的 Producer 运行起来准备发送消息时抛异常如下
  • “ No route info of this topic ” 异常产生的原因可能是，自己当时的原因恰好是第三条：
  1. Broker 禁止自动创建 Topic，且用户没有通过手工方式创建 Topic
  2. Broker 没有正确连接到 Name Server
  3. Producer 没有正确连接到 Name Server 
  1. 17:28:23.123 [main] DEBUG i.n.u.i.l.InternalLoggerFactory - Using SLF4J as the default logging framework
  2. org.apache.rocketmq.client.exception.MQClientException: No route info of this topic, TopicTest1
  3. See http://rocketmq.apache.org/docs/faq/ for further details.
  4. 	at org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.sendDefaultImpl(DefaultMQProducerImpl.java:610)
  5. 17:28:29.595 [NettyClientSelector_1] INFO  RocketmqRemoting - closeChannel: close the connection to remote address[] result: true
  6. 	at org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.send(DefaultMQProducerImpl.java:1223)
  7. 	at org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.send(DefaultMQProducerImpl.java:1173)
  8. 	at org.apache.rocketmq.client.producer.DefaultMQProducer.send(DefaultMQProducer.java:214)
  9. 	at com.lct.quickstart.Producer.main(Producer.java:56)
  10. 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  11. 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  12. 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  13. 	at java.lang.reflect.Method.invoke(Method.java:498)
  14. 	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)

解决办法

  • 排查1：Broker 禁止自动创建 Topic，且用户没有通过手工方式创建 Topic：
  • 可以在 Rocket_HOME/distribution/target/apache-rocketmq 下执行 " sh bin/mqbroker -m " 来查看 broker 的配置参数
  • 如下所示，autoCreateTopicEnable=true 证明是没有问题的
  1. [root@localhost apache-rocketmq]# sh ./bin/mqbroker -m
  2. 2018-08-12 01\:27\:28 INFO main - namesrvAddr=
  3. 2018-08-12 01\:27\:28 INFO main - brokerIP1=192.168.58.129
  4. 2018-08-12 01\:27\:28 INFO main - brokerName=localhost.localdomain
  5. 2018-08-12 01\:27\:28 INFO main - brokerClusterName=DefaultCluster
  6. 2018-08-12 01\:27\:28 INFO main - brokerId=0
  7. 2018-08-12 01\:27\:28 INFO main - autoCreateTopicEnable=true
  8. 2018-08-12 01\:27\:28 INFO main - autoCreateSubscriptionGroup=true
  9. 2018-08-12 01\:27\:28 INFO main - rejectTransactionMessage=false
  10. 2018-08-12 01\:27\:28 INFO main - fetchNamesrvAddrByAddressServer=false
  11. 2018-08-12 01\:27\:28 INFO main - transactionTimeOut=3000
  12. 2018-08-12 01\:27\:28 INFO main - transactionCheckMax=5
  13. 2018-08-12 01\:27\:28 INFO main - transactionCheckInterval=60000
  14. 2018-08-12 01\:27\:28 INFO main - storePathRootDir=/root/store
  15. 2018-08-12 01\:27\:28 INFO main - storePathCommitLog=/root/store/commitlog
  16. 2018-08-12 01\:27\:28 INFO main - flushIntervalCommitLog=500
  17. 2018-08-12 01\:27\:28 INFO main - commitIntervalCommitLog=200
  18. 2018-08-12 01\:27\:28 INFO main - flushCommitLogTimed=false
  19. 2018-08-12 01\:27\:28 INFO main - deleteWhen=04
  20. 2018-08-12 01\:27\:28 INFO main - fileReservedTime=72
  21. 2018-08-12 01\:27\:28 INFO main - maxTransferBytesOnMessageInMemory=262144
  22. 2018-08-12 01\:27\:28 INFO main - maxTransferCountOnMessageInMemory=32
  23. 2018-08-12 01\:27\:28 INFO main - maxTransferBytesOnMessageInDisk=65536
  24. 2018-08-12 01\:27\:28 INFO main - maxTransferCountOnMessageInDisk=8
  25. 2018-08-12 01\:27\:28 INFO main - accessMessageInMemoryMaxRatio=40
  26. 2018-08-12 01\:27\:28 INFO main - messageIndexEnable=true
  27. 2018-08-12 01\:27\:28 INFO main - messageIndexSafe=false
  28. 2018-08-12 01\:27\:28 INFO main - haMasterAddress=
  29. 2018-08-12 01\:27\:28 INFO main - brokerRole=ASYNC_MASTER
  30. 2018-08-12 01\:27\:28 INFO main - flushDiskType=ASYNC_FLUSH
  31. 2018-08-12 01\:27\:28 INFO main - cleanFileForciblyEnable=true
  32. 2018-08-12 01\:27\:28 INFO main - transientStorePoolEnable=false
  33. [root@localhost apache-rocketmq]#
  • 排查2：Broker 没有正确连接到 Name Server
  • 如下所示，启动 broker 的时候，只要看到了 The broker[localhost.localdomain, 192.168.58.129:10911] boot success. serializeType=JSON and name server is localhost:9876  字样就说明是成功的
  1. [root@localhost apache-rocketmq]# nohup sh bin/mqbroker -n localhost:9876 &
  2. [2] 3256
  3. [1]   退出 143              nohup sh bin/mqbroker -n localhost:9876
  4. [root@localhost apache-rocketmq]# nohup: 忽略输入并把输出追加到"nohup.out"
  5. tail -f ~/logs/rocketmqlogs/broker.log 
  6. 2018-08-11 23:48:26 INFO main - load exist subscription group, SubscriptionGroupConfig [groupName=CID_ONSAPI_OWNER, consumeEnable=true, consumeFromMinEnable=true, consumeBroadcastEnable=true, retryQueueNums=1, retryMaxTimes=16, brokerId=
  7. 2018-08-11 23:48:31 WARN main - Load default discard message hook service: DefaultTransactionalMessageCheckListener
  8. 2018-08-11 23:48:31 INFO FileWatchService - FileWatchService service started
  9. 2018-08-11 23:48:31 INFO PullRequestHoldService - PullRequestHoldService service started
  10. 2018-08-11 23:48:31 INFO brokerOutApi_thread_1 - register broker to name server localhost:9876 OK
  11. 2018-08-11 23:48:31 INFO main - Start transaction service!
  12. 2018-08-11 23:48:31 INFO main - The broker[localhost.localdomain, 192.168.58.129:10911] boot success. serializeType=JSON and name server is localhost:9876
  13. 2018-08-11 23:48:41 INFO BrokerControllerScheduledThread1 - dispatch behind commit log 0 bytes
  14. 2018-08-11 23:48:41 INFO BrokerControllerScheduledThread1 - Slave fall behind master: 906412 bytes
  15. 2018-08-11 23:48:41 INFO brokerOutApi_thread_2 - register broker to name server localhost:9876 OK
  • 排查3：Producer 没有正确连接到 Name Server 
  • 当时一时糊涂 Linux 上开启了 Broker 端口是 9876，然后自己并没有在防护墙中开启此端口，所以导致客户端 Producer 无论如何也连接不上
  • 如下所示，命令分别含义是：
  1. 查看防护墙开放的端口，此时没有 9876
  2. 设置防火墙开放9876 端口
  3. 重新加载 firewall，修改配置后，必须重新加载才能生效：firewall-cmd --reload 
  4. 再次查看防火墙开放的端口，此时已有 9876
  1. [root@localhost apache-rocketmq]# firewall-cmd --zone=public --list-ports
  2. 8090/tcp 80/tcp 8080/tcp
  3. [root@localhost apache-rocketmq]# firewall-cmd --zone=public --add-port=9876/tcp --permanent
  4. success
  5. [root@localhost apache-rocketmq]# firewall-cmd --reload
  6. success
  7. [root@localhost apache-rocketmq]# firewall-cmd --zone=public --list-ports
  8. 9876/tcp 8090/tcp 80/tcp 8080/tcp
  9. [root@localhost apache-rocketmq]#

RemotingTooMuchRequestException: sendDefaultImpl call timeout

异常说明

  • 在客户端的 Producer 运行起来准备发送消息时抛异常如下
  • 因为使用的是虚拟机，设置内存也只有1G，所以从 Windows 上开发连接 虚拟机中的 nameServer 时要经过 Linux 系统的防火墙，而防火墙一般都会有超时的机制，在网络连接长时间不传输数据时，会关闭这个 TCP 的会话，关闭后再读写，就有可能导致这个异常。
  1. 16:22:37.403 [main] DEBUG i.n.u.i.l.InternalLoggerFactory - Using SLF4J as the default logging framework
  2. 16:22:40.994 [NettyClientSelector_1] INFO  RocketmqRemoting - closeChannel: close the connection to remote address[] result: true
  3. Exception in thread "main" org.apache.rocketmq.remoting.exception.RemotingTooMuchRequestException: sendDefaultImpl call timeout
  4. 	at org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.sendDefaultImpl(DefaultMQProducerImpl.java:588)
  5. 	at org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.send(DefaultMQProducerImpl.java:1223)
  6. 	at org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.send(DefaultMQProducerImpl.java:1173)
  7. 	at org.apache.rocketmq.client.producer.DefaultMQProducer.send(DefaultMQProducer.java:214)
  8. 	at com.lct.test.quickStart.Producer.main(Producer.java:28)
  9. 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  10. 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  11. 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  12. 	at java.lang.reflect.Method.invoke(Method.java:498)
  13. 	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
  14. 16:22:41.772 [NettyClientSelector_1] INFO  RocketmqRemoting - closeChannel: close the connection to remote address[] result: true
  15. 16:23:11.770 [NettyClientSelector_1] INFO  RocketmqRemoting - closeChannel: close the connection to remote address[] result: true

解决办法

  • 因为现在主要是熟练 RocketMQ 的 API，所以直接关闭了 Linux 的防火墙，实际中如果买的是如 阿里云的云主机，应该会好一些
  1. [root@localhost ~]#  systemctl status firewalld
  2. ● firewalld.service - firewalld - dynamic firewall daemon
  3.    Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
  4.    Active: active (running) since 六 2018-08-11 23:20:53 CST; 56min ago
  5.  Main PID: 877 (firewalld)
  6.    CGroup: /system.slice/firewalld.service
  7.            └─877 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
  8.  
  9. 8月 11 23:20:50 localhost.localdomain systemd[1]: Starting firewalld - dynamic firewall.....
  10. 8月 11 23:20:53 localhost.localdomain systemd[1]: Started firewalld - dynamic firewall ...n.
  11. Hint: Some lines were ellipsized, use -l to show in full.
  12. [root@localhost ~]#
  • 如上所示防火墙是开的，下面指令关闭防火墙
  1. [root@localhost ~]# systemctl stop firewalld
  2. [root@localhost ~]#  systemctl status firewalld
  3. ● firewalld.service - firewalld - dynamic firewall daemon
  4.    Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
  5.    Active: inactive (dead) since 日 2018-08-12 00:19:39 CST; 2s ago
  6.   Process: 877 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=exited, status=0/SUCCESS)
  7.  Main PID: 877 (code=exited, status=0/SUCCESS)
  8.  
  9. 8月 11 23:20:50 localhost.localdomain systemd[1]: Starting firewalld - dynamic firewall.....
  10. 8月 11 23:20:53 localhost.localdomain systemd[1]: Started firewalld - dynamic firewall ...n.
  11. 8月 12 00:19:38 localhost.localdomain systemd[1]: Stopping firewalld - dynamic firewall.....
  12. 8月 12 00:19:39 localhost.localdomain systemd[1]: Stopped firewalld - dynamic firewall ...n.
  13. Hint: Some lines were ellipsized, use -l to show in full.
  14. [root@localhost ~]#

 

 

 

rocketmq出现org.apache.rocketmq.client.exception.MQClientException: No route info of this topic: Topic
qq_41188174的博客
01-14 7779
本来项目好好的，突然出现rocketmq消息队列出现故障，查看项目日志出现以下错误：org.apache.rocketmq.client.exception.MQClientException: send message Exception For more information, please visit the url, http://rocketmq.apache.org/docs/faq/ at org.apache.rocketmq.client.impl.producer.DefaultMQ
RocketMq Exception "connect to <：10909> failed"问题--雷锋
cmq591117730的博客
06-16 8648
之前使用RocketMQ，遇到过“connect to failed”问题。最近使用的时候又遇到了。这里总结一下。 1、代码描述 2、异常描述 [java] view plain copy com.alibaba.rocketmq.client.exception.MQClientException: Sen
sendDefaultImpl call timeout（rocketmq）
最新发布
2301_79140115的博客
06-07 354
修改broker 的配置如下，注意brokerIP1 这个配置必须有，不然 rocketmq-console 显示依然是内网地址。中的mq的话，需要设置超时时间。因为可能是超时导致的。
RocketMQ的NameServer安装报错解决
weixin_34092455的博客
07-14 480
为什么80%的码农都做不了架构师？>>> ...
org.apache.rocketmq.client.exception.MQClientException: No route info of this topic, TopicTest异常解决
男人要霸气的博客
12-10 2824
使用RocketMQ发送消息抛出异常，异常如下： org.apache.rocketmq.client.exception.MQClientException: No route info of this topic, TopicTest See http://rocketmq.apache.org/docs/faq/ for further details. at org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.sendDef
五.RocketMQ理论及常见问题处理方案
醉卧雕龙舫，的博客
07-07 1199
RocketMq理论及常见问题处理方案
RocketMQ常见问题与深度解析
禅与计算机程序设计的艺术
02-19 853
通俗来说一个消息消费失败并重试达到最大次数后，MQ就会将其放到死信队列中。超过三天该消息就会被销毁。需要补充的时死信队列是针对一个group id为单位创建的队列，如果一个gourp中都没有死信的话，那么MQ就不会为这个组创建死信队列。
RocketMQ常见问题分析
weixin_43134177的博客
12-24 1100
而RocketMQ的事务消息机制，实际上只保证了整个事务消息的一半，他保证的是订单系统下单和发消息这两个事件的事务一致性，而对下游服务的事务并没有保证。目前来看，也是业内最好的降级方案。我们需要注意下，在事务消息的处理机制中，未知状态的事务状态回查是由RocketMQ的Broker主动发起的。往MQ发一个延迟1分钟的消息，消费到这个消息后去检查订单的支付状态，如果订单已经支付，就往下游发送下单的通知。最简单的方式是启动一个定时任务，每隔一段时间扫描订单表，比对未支付的订单的下单时间，将超过时间的订单回收。
2023 RocketMQ常见面试题50道
04-04
- RocketMQ 提供了多种策略来保证消息的可靠传输，如事务消息、DLQ（Dead Letter Queue）等，这些特性可以处理异常情况并确保消息最终被正确处理。 8. **Consumer 端消息不丢失**： - Consumer 应正确处理 Ack，...
rocketMq消息堆积处理方式
qq_36042938的博客
11-10 1209
云消息队列 RocketMQ 版的消息发送至Broker节点后，配置了Group ID的客户端根据当前的消费位点，从Broker节点拉取部分消息到本地进行消费。一般情况下，客户端从Broker节点拉取消息的过程不会导致消息堆积，主要是客户端本地消费过程中，由于消费耗时过长或消费并发度较小等原因，导致客户端消费能力不足，出现消息堆积的问题。针对某些特殊业务场景，如果消息堆积已经影响到业务运行，且堆积的消息本身可以跳过不消费，您可以通过重置消费位点跳过这些堆积的消息从最新位点开始消费，快速恢复业务。
一篇文章彻底解决RocketMq的疑难杂症之：org.apache.rocketmq.client.exception.MQClientException: No route info of thi
热门推荐
weixin_38232096的博客
09-27 1万+
解决 一共有四个原因： 1 brocker买有连接到mqnameserv 2 producer没有连接到mqnameserv 3 topic没有创建 4 防火墙 说明： rocktMq中nameserv相当于一个zookeeper，充当一个注册的角色，所以brocker和我们的代码producer是通过nameserv来进行同行的。 brocker的启动命令中 -n xxxx:9876 就是指定 mqnameserv ，producer的代码中 也是 producer.setNamesrvAddr(“xxx
rocketmq 初体验（五）org.apache.rocketmq.client.exception.MQClientException: No route info of this topic
游语
11-12 1157
org.apache.rocketmq.client.exception.MQClientException: No route info of this topic, Jodie_topic_1023 报错log org.apache.rocketmq.client.exception.MQClientException: No route info of this topic, Jodie_t...
org.apache.rocketmq.client.exception.MQClientException: No route info of this topic
qq_24084605的博客
07-15 398
DefaultMQProducer producer= new DefaultMQProducer(producerGroup); //设置namesrv地址namesrv地址不可以加http:////producer.setNamesrvAddr("http://127.0.0.1:9876"); 改为 producer.setNamesrvAddr("127.0.0.1:9876"); producer.setVipChannelEnabled(false);//关闭vip通道 //启动生...
使用消息队列的接口，报error:org.apache.rocketmq.client.exception.MQClientException: No route info of this topic
jyxzfw的博客
11-19 1239
问题描述： 使用消息队列的接口，都报 error:org.apache.rocketmq.client.exception.MQClientException: No route info of this topic: XXX 问题。 查找原因： 进入RocketMQ-Console控制台 发现OPS有NameSvrAddrList列表 但是在Cluster集群中没有分片 看一下服务器上的broker分片，和服务器内存 猜测内存不够，所以brocker没有启动起来 问题解决： ..
rocketmq常见问题
05-17
### RocketMQ 常见问题及解决方法 #### 一、消息幂等问题 在分布式系统中，由于网络抖动或其他异常情况可能导致消息重复发送或多次消费。为了应对这一问题，通常需要实现消费幂等。 - **什么是消费幂等** 消费幂等是指同一条消息无论被消费多少次，其最终的结果是一致的[^3]。 - **消息重复的场景分析** - 发送时消息重复：在网络不稳定的情况下，可能会导致消息重复发送[^3]。 - 消费时消息重复：消费者在处理过程中可能出现异常中断，重新拉取消息后再次消费。 - Rebalance时消息重复：当消费者组成员发生变化时，可能引发消息重复分配和消费[^3]。 - **通用解决方案** 实现消费幂等的关键在于两个要素：幂等令牌与唯一性处理逻辑[^3]。通过记录已消费过的消息ID或者业务流水号等方式，确保同一消息不会被执行两次操作。 --- #### 二、消息堆积问题 消息堆积通常是由于生产速度快于消费速度造成的。以下是常见的原因及其优化措施： - **产生原因分析** - 消息拉取效率低下：可能是由于网络带宽不足或客户端配置不合理所致[^2]。 - 消息消费耗时过长：某些复杂业务逻辑增加了单条消息的平均处理时间[^2]。 - 消费并发度过低：默认情况下消费者的线程池大小有限制，无法充分利用硬件资源。 - **如何避免消息堆积和消费延迟** - 提高消费能力：增加消费者的实例数量以分摊负载；调整`consumeThreadMin` 和 `consumeThreadMax` 参数来动态扩展消费线程数[^4]。 - 调优业务逻辑：减少每条消息的实际执行开销，比如批量提交数据库更新而不是逐条写入[^4]。 - 设置合理的超时机制：对于长时间未完成的任务可以主动放弃并放入死信队列进一步排查[^4]。 --- #### 三、消息清理问题 随着时间推移，存储空间会被大量历史数据占据。因此定期清除陈旧无用的数据成为必要之举。 - Broker提供了TTL(Time To Live)参数用于定义消息存活期限，超过该时间段后的消息将会自动删除[^3]。 --- #### 四、消息过滤问题 根据具体需求筛选感兴趣的内容有助于降低不必要的传输成本。 - **Tag方式过滤**: 使用标签标记不同类型的消息，在订阅阶段指定感兴趣的tag即可达到目的。 - **SQL表达式过滤**: 支持基于属性字段构建复杂的条件语句来进行精确匹配。 示例代码展示两种不同类型的过滤器应用： ```java // Tag 过滤 DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("example_group"); consumer.subscribe("TopicTest", "TagA || TagB"); // SQL 表达式过滤 consumer.subscribe("TopicTest", "price >= 5 AND city='Beijing'"); ``` --- #### 五、消息重试问题 无论是因为瞬态错误还是永久失效都需要有相应的恢复手段保障服务质量。 - 对于普通的乱序消息，默认支持最多16次指数退避式的再尝试机会[^2]； - 如果涉及严格的因果关系维护则需启用有序模式下的特别策略——一旦发现失败即暂停后续项直到当前障碍解除为止[^2]。 特殊情况如超出最大允许范围仍未成功，则转入专门设立的DLQ(Dead Letter Queue)[^4]供人工介入审查。 --- #### 六、如何保证消息不丢失 这是衡量一款中间件产品成熟度的重要指标之一。 - Producer层面可通过开启事务特性确认投递状态后再做下一步动作； - Consumer方面除了常规的心跳检测外还应周期性的向远程汇报进度以防万一中途崩溃遗漏部分已完成的工作成果[^5]。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值