RocketMQ常见错误与解决方案

源引思

已于 2023-07-21 11:56:14 修改

阅读量4.2k

点赞数 1

分类专栏： rocketmq 文章标签： rocketmq

于 2023-07-21 11:14:49 首次发布

本文链接：https://blog.youkuaiyun.com/csdn5266/article/details/131846628

版权

rocketmq 专栏收录该内容

1 篇文章

订阅专栏

本文介绍了RocketMQ在处理主题路由、消息发送超时以及SystemBusy错误时的机制和解决方案。包括检查Topic是否存在、Broker的自动创建Topic设置、客户端与Nameserver的连接一致性，以及如何调整发送超时时间和重试策略。对于PageCache繁忙问题，提出了启用transientStorePoolEnable和集群扩容的解决办法。

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

1、No route info of this topic

如果Broker开启了自动创建Topic，在启动的时候会默认创建主题：TBW102，并会随着Broker发送到Nameserver的心跳包汇报给Nameserver，继而从Nameserver查询路由信息时能返回路由信息。
消息发送者在消息发送时首先会查本地缓存，如果本地缓存中存在，直接返回路由信息。
如果缓存不存在，则向Nameserver查询路由信息，如果Nameserver存在该路由信息，就直接返回。
如果Nameserver不存在该topic的路由信息，如果没有开启自动创建主题，则抛出 No route info of this topic。
如果开启了自动创建主题，则使用默认主题向Nameserver查询路由信息，并使用默认Topic的路由信息为自己的路由信息，将不会抛出 No route info of this topic。

解决思路

1. 通过rocketmq-console查询Topic是否存在

2. 查看配置文件, Broker是否开启了自动创建Topic，参数为：autoCreateTopicEnable, 该参数默认为true,但在生产环境不建议开启。

3. 如果开启了自动创建Topic，但还是抛出这个错误，这个时候请检查客户端(Producer)连接的Nameserver地址是否与Broker中配置的nameserver地址是否一致。

2、消息发送超时

RocketMQ每一分钟打印前一分钟内消息发送的耗时情况分布

如果100-200ms及以上的区间超过20个后，说明Broker确实存在一定的瓶颈

[<=0ms] 小于0ms，即微妙级别的。
[0~10ms] 小于10ms的个数。
[10~50ms]　大于10ms小
于50ms的个数

cd /home/logs/rocketmqlogs/
grep -n 'PAGECACHERT' store.log | more

解决思路

减少消息发送的超时时间，增加重试次数，并增加快速失败的最大等待时长

1. 快速失败导致的错误为SYSTEM_BUSY，并不会触发重试，适当增大Broker端快速失败的时长

＃该值默认为200，表示200ms
waitTimeMillsInSendQueue=1000

2. 如果RocketMQ的客户端版本为4.3.0以下版本(不含4.3.0) 将超时时间设置消息发送的超时时间为500ms，并将重试次数设置为6次(这个可以适当进行调整，尽量大于3)

    DefaultMQProducer producer = new DefaultMQProducer("dw_test_producer_group");
    producer.setNamesrvAddr("127.0.0.1:9876");
    producer.setRetryTimesWhenSendFailed(5);// 同步发送模式：重试次数
    producer.setRetryTimesWhenSendAsyncFailed(5);// 异步发送模式：重试次数
    producer.start();
    producer.send(msg,500);// 消息发送超时时间

3. 如果RocketMQ的客户端版本为4.3.0及以上版本如果客户端版本为4.3.0及其以上版本，由于其设置的消息发送超时时间为所有重试的总的超时时间，故不能直接通过设置RocketMQ的发送API的超时时间，而是需要对其API进行包装，重试需要在外层收到进行

    public static SendResult send(DefaultMQProducer producer, Message msg, int retryCount) {
        Throwable e = null;
        for (int i = 0; i < retryCount; i++) {
            try {
                return producer.send(msg, 500); //设置超时时间，为500ms，内部有重试机制
            } catch (Throwable e2) {
                e = e2;
            }
        }
        throw new RuntimeException("消息发送异常", e);
    }

配置application.yaml

rocketmq:
  name-server: http://127.0.0.0:11800
  producer:
    group: topic_receive_default_test # 必须指定group
    send-message-timeout: 30000 # 消息发送超时时长，默认3s
    retry-times-when-send-failed: 3 # 同步发送消息失败重试次数，默认2
    retry-times-when-send-async-failed: 3 # 异步发送消息失败重试次数，默认2

3、System busy、Broker busy

常见错误

[REJECTREQUEST]system busy
too many requests and system thread pool busy
[PC_SYNCHRONIZED]broker busy
[PCBUSY_CLEAN_QUEUE]broker busy
[TIMEOUT_CLEAN_QUEUE]broker busy

相关说明

判断pagecache是否忙的依据就是在写入消息时，在向内存追加消息时加锁的时间，默认的判断标准是加锁时间超过1s，就认为是pagecache压力大，向客户端抛出相关的错误日志。
发送线程池挤压的拒绝策略在RocketMQ中处理消息发送的是一个只有一个线程的线程池，内部会维护一个有界队列，默认长度为1W，如果当前队列中挤压的数量超过1w，执行线程池的拒绝策略，从而抛出[too many requests and system thread pool busy]错误。
Broker端快速失败默认情况下Broker端开启了快速失败机制，就是在Broker端还未发生pagecache繁忙(加锁超过1s)的情况，但存在一些请求在消息发送队列中等待200ms的情况，RocketMQ会不再继续排队，直接向客户端返回system busy，但由于rocketmq客户端目前对该错误没有进行重试处理，所以在解决这类问题的时候需要额外处理。

PageCache繁忙解决方案

在broker中配置文件中增加如下配置, 开启transientStorePoolEnable机制

transientStorePoolEnable=true

消息先写入到堆外内存中，该内存由于启用了内存锁定机制，故消息的写入是接近直接操作内存，性能能得到保证。
消息进入到堆外内存后，后台会启动一个线程，一批一批将消息提交到pagecache，即写消息时对pagecache的写操作由单条写入变成了批量写入，降低了对pagecache的压力。引入transientStorePoolEnable会增加数据丢失的可能性，如果Broker JVM进程异常退出，提交到PageCache中的消息是不会丢失的，但存在堆外内存(DirectByteBuffer)中但还未提交到PageCache中的这部分消息，将会丢失。但通常情况下，RocketMQ进程退出的可能性不大，通常情况下，如果启用了transientStorePoolEnable，消息发送端需要有重新推送机制(补偿思想)。
扩容如果在开启了transientStorePoolEnable后，还会出现pagecache级别的繁忙，那需要集群进行扩容，或者对集群中的topic进行拆分，即将一部分topic迁移到其他集群中，降低集群的负载。

在RocketMQ出现pagecache繁忙造成的broker busy，RocketMQ Client会有重试机制。不建议开启该机制,尽量使用扩容解决

TIMEOUT_CLEAN_QUEUE 解决方案

在broker的配置文件中增加如下配置,适当增大快速失败的判断标准

＃该值默认为200，表示200ms
waitTimeMillsInSendQueue=1000