Topic太多！RocketMQ炸了！

太过爱你忘了你带给我的痛 2023-09-25 23:38 11阅读 0赞

网上博客常说，kafka的topic数量过多会影响kafka，而RocketMQ不会受到topic数量影响。

但是，果真如此吗？

最近排查一个问题，发现RocketMQ稳定性同样受到topic数量影响！！

好了，一起来回顾下这次问题排查吧，**最佳实践**和**引申思考**放在最后，千万不要错过。

### 1、问题描述 ###

我们的RocketMQ集群为4.6.0版本，按照3个nameserver，2个broker，每个broker为主从双节点部署。

![format_png][]

部署架构

某天收到警报，broker-b突然从nameserver掉线，且主从双节点都无法重新注册。

### 2、初步排查 ###

#### 2.1 检查进程存活&网络 ####

因为控制台上显示broker-a正常，因此可以认为 nameserver、broker-a都是正常的，问题出在broker-b上。

当时第一反应是broker-b进程挂了，或者网络不通了。

登陆broker节点，看到进程依然存活。

然后通过telnet检查和nameserver的联通性，显示正常，网络没有问题。

#### 2.2 检查日志 ####

检查broker日志，马上发现了异常。

2023-01-09 14:07:37 WARN brokerOutApi_thread_3 - registerBroker Exception, mqnameserver3:xxxx
    org.apache.rocketmq.remoting.exception.RemotingSendRequestException: send request to <qnameserver3/xx.xx.xx.xxx:xxxx> failed
        at org.apache.rocketmq.remoting.netty.NettyRemotingAbstract.invokeSyncImpl(NettyRemotingAbstract.java:429) ~[rocketmq-remoting-4.6.0.jar:4.6.0]
        at org.apache.rocketmq.remoting.netty.NettyRemotingClient.invokeSync(NettyRemotingClient.java:373) 
    ......
    复制代码

异常比较明确，broker请求nameserver失败，所以导致无法注册到集群中。

那为什么会注册失败呢？没有非常明确的提示，因此去看下nameserver上的日志信息。

2023-01-09 14:09:26 ERROR NettyServerCodecThread_1 - decode exception, xx.xxx.xx.xxx:40093
    io.netty.handler.codec.TooLongFrameException: Adjusted frame length exceeds 16777216: 16777295 - discarded
        at io.netty.handler.codec.LengthFieldBasedFrameDecoder.fail(LengthFieldBasedFrameDecoder.java:499) [netty-all-4.0.42.Final.jar:4.0.42.Final]
    ......
    复制代码

这个异常看起来是nameserver上的netty抛出的，请求过大抛出了异常。

根据日志关键字，直接定位到了源码，确实有默认的大小限制，并且可以通过  
com.rocketmq.remoting.frameMaxLength进行控制。

#### 2.3 源码分析 ####

虽然找到了异常的直接原因，**但是为什么broker突然会有这么大的请求？是什么带来的？**

从broker的warning日志中，并没有办法看到更多有效信息。

因此，还是得深入分析下broker上的源码。根据日志关键字，很快找到broker中的异常位置

![format_png 1][]

broker异常位置

> 注意！这里通过遍历nameserverlist，在线程池中异步注册，跟后面的一个小知识点有关。

从源码中可以分析出，如果有过大的请求的话，应该就是这个requestBody引起，它携带了大量topic信息topicConfigWrapper。

但是我们在控制台上看到当前集群中，只有300+topic（这里其实是一个误区，最后会解释），理论上来说是非常小的，为什么会超出容量限制呢？

看了下源码上下文，并没有对reqeustBody或者topicConfigWrapper有相关日志的记录，因此，还是需要arthas来看看了。

#### 2.4 arthas定位 ####

直接通过arthas定位实际内存值

watch org.apache.rocketmq.broker.out.BrokerOuterAPI registerBrokerAll {params,returnObj} -x 3
    复制代码

查看结果

![format_png 2][]

内存中实际topic数量

啥玩意？！

topicConfigTable的map大小为size=71111？！！

进一步看看这些topic里面都是些啥？我们调整下arthas的参数-x为4，改变watch变量的深度。

![format_png 3][]

发现问题了！

我们看到了大量%RETRY%开头的topic。

### 3、根本原因 ###

至此，根本原因就能明确了。

RETRY topic过多，导致 broker 向 nameserver 发送心跳（定时发送注册请求）时，心跳请求中携带的 body 上的 topic 信息过大，超过了 nameserver 上使用的 NettyDecoder.java 限制的 16M （默认值），心跳请求失败，所以broker掉线。

### 4、恢复 ###

既然问题基本确定了，那么先尝试恢复吧。

前面已经看到了对最大请求体的配置，因此，我们在bin/runserver.sh中添加一个JAVA\_OPTION对  
com.rocketmq.remoting.frameMaxLength进行配置。然后重启nameserver。

重新观察broker，果然重启成功了。

2023-01-09 16:03:55 INFO brokerOutApi_thread_3 - register broker[0]to name server mqnameserver4:9876 OK
    2023-01-09 16:03:55 INFO brokerOutApi_thread_4 - register broker[0]to name server mqnameserver2:9876 OK
    复制代码

当然，这只是临时恢复措施，后面重点要思考以下问题并进行优化：

*  RETRY topic数量这么多是否正常？是否可以清理无效topic？
 *  如何做好后续的topic数量监控告警？

### 5、最佳实践 ###

#### 5.1 定时删除无效RETRY topic ####

考虑使用定时任务扫描所有业务topic下的消费组，再根据消费组状态（状态为not\_online的消费组），拼出对应RETRY topic进行删除。以上步骤均有开源MQ sdk 的 api 可以调用。

即使后续消费组重新使用，RETRY topic 也会重新创建，不影响消费。

#### 5.2 topic总数监控 ####

前面说到在控制台上看到当前集群中只有300+topic，这里其实是一个误区，只勾选了NORMAL类型的topic，并没有注意RETRY、DLQ、SYSTEM类型的topic。

![format_png 4][]

控制台误区

而这次几万个topic基本都是RETRY类型的。

后续需要添加topic数量监控（包括RETRY类型），防止由于topic数量过多，导致broker注册失败。

### 6、引申思考 ###

#### 6.1 RETRY topic是什么？为什么有这么多？ ####

这需要从RocketMQ的重试机制与死信机制说起。

RocketMQ 提供了自带的重试机制，消息消费失败或超时，会被投递到 RETRY topic。RETRY topic 里的消息会按照延时队列的延时时间进行消费，这样也避免了有问题的消息阻塞正常消费。

RETRY topic 里保存的是消费状态为 consumer\_later 的消息，在重试达到 16 次（默认值）以后，消息会进入死信队列（本质上也是一个新的topic类型，DLS topic)。

DLQ topic在使用时才会创建，因此不会像RETRY topic 这样大量膨胀。

但是，RETRY topic不一样。它是由RocketMQ服务端自动创建，创建的时机有两个：

*  消费失败的时候，将消息发送回 broker，这时候会在服务端创建RETRY topic

![format_png 5][]

消费失败创建RETRY topic

*  consumer client 和服务端保持心跳时创建RETRY topic

![format_png 6][]

心跳时创建 retry topic

线下环境的消费组存在大量的临时测试group，而 RocketMQ会给每个实际存在的消费组创建RETRY topic，导致 RETRY topic 大量膨胀。

#### 6.2 如果所有消息自动重试，顺序消息会乱序吗？ ####

我们知道，RocketMQ中包含三种消息类型：普通消息、普通有序消息、严格有序消息。

三种消息的类型介绍如下：

*  普通消息：消息是无序的，任意发送发送哪一个队列都可以。
 *  普通有序消息：同一类消息(例如某个用户的消息)总是发送到同一个队列，在异常情况下，也可以发送到其他队列。
 *  严格有序消息：消息必须被发送到同一个队列，即使在异常情况下，也不允许发送到其他队列。

对于这三种类型的消息，RocketMQ对应的提供了对应的方法来分别消息：

//发送普通消息，异常时默认重试
    public SendResult send(Message msg)
    
    //发送普通有序消息，通过selector动态决定发送哪个队列，异常默认不重试，可以用户自己重试，并发送到其他队列
    public SendResult send(Message msg, MessageQueueSelector selector, Object arg)
    
    //发送严格有序消息，通过指定队列，保证严格有序，异常默认不重试
    public SendResult send(Message msg, MessageQueue mq)
    复制代码

所以RocketMQ客户端的生产者默认重试机制，只会普通消息有作用。对于普通有序消息、严格有序消息是没有作用。

#### 6.3 nameserver数据一致性问题 ####

在通过修改启动参数  
com.rocketmq.remoting.frameMaxLength进行临时恢复的时候，发现一个问题：日志恢复了，但是控制台上却仍然没有显示broker-b。

排查了下发现，由于nameserver有4台，只重启了一台，而控制台连接访问的nameserver是另一台，所以显示不正确。

通过切换控制台nameserver地址，就能看到broker-b了。

为什么不同nameserver允许数据不一致呢？

前面在排查的过程中也发现了，broker源码中通过遍历nameserverlist，在线程池中异步注册topic信息到nameserver。

![format_png 7][]

注册逻辑

而这也体现了RocketMQ中对nameserver的设计思想。

**nameserver是一个AP组件，而不是CP组件！**

在 RocketMQ 中 Nameserver 集群中的节点相互之间不通信，各节点相互独立，实现非常简单。但同样会带来一个问题：

Topic 的路由信息在各个节点上会出现不一致。

那 Nameserver 如何解决这个问题呢？RocketMQ 的设计者采取的方案是不解决，即为了保证 Nameserver 的高性能，允许存在这些缺陷。

**NameServer之间不通信，消息发送端通过PULL方式更新topic信息，无法及时感知路由信息的变化，因此引入了消息发送重试（只针对普通消息）与故障规避机制来保证消息的发送高可用。**

事实上，在RocketMQ的早期版本，即MetaQ 1.x和MetaQ 2.x阶段，也是依赖Zookeeper的（CP型组件）。但MetaQ 3.x（即RocketMQ）却去掉了ZooKeeper依赖，转而采用自己的NameServer。

NameServer数据不一致，比较大的影响就是topic的队列会存在负载不均衡的问题，以及消费端的重复消费问题，这些问题对消息队列来说都是可以忍受的，只要最终能保持一致，恢复平衡即可。

> 都看到最后了，原创不易，点个关注，点个赞吧～

[format_png]: https://img-blog.csdnimg.cn/img_convert/9ed593135f2520b18f168f6f72378b2c.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/3c1ef947a8cf0d4d19651f92fdbbe533.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/99e0d878d4dddb75b25e8cdaed358508.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/92ef07b493e2bb729a15e17156b9c302.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/9b265556ef30718e33e098616c016e4f.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/5e4e9bb8c3f58b2b0fc7edc3e3a0ecc7.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/350f120949238fa334bd7a75a8938aec.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/21dc28b2a5409c34c044d4affee54822.webp?x-oss-process=image/format,png