網上博客常說，kafka的topic數量過多會影響kafka，而RocketMQ不會受到topic數量影響。

但是，果真如此嗎？

最近排查一個問題，發現RocketMQ穩定性同樣受到topic數量影響！！

好了，一起來回顧下這次問題排查吧，最佳實踐和引申思考放在最后，千萬不要錯過。

1、問題描述

我們的RocketMQ集群為4.6.0版本，按照3個nameserver，2個broker，每個broker為主從雙節點部署。

部署架構

某天收到警報，broker-b突然從nameserver掉線，且主從雙節點都無法重新注冊。

2、初步排查

（1）檢查進程存活&網絡

因為控制臺上顯示broker-a正常，因此可以認為 nameserver、broker-a都是正常的，問題出在broker-b上。

當時第一反應是broker-b進程掛了，或者網絡不通了。

登陸broker節點，看到進程依然存活。

然后通過telnet檢查和nameserver的聯通性，顯示正常，網絡沒有問題。

（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進行控制。

（3）源碼分析

雖然找到了異常的直接原因，但是為什么broker突然會有這么大的請求？是什么帶來的？

從broker的warning日志中，并沒有辦法看到更多有效信息。

因此，還是得深入分析下broker上的源碼。根據日志關鍵字，很快找到broker中的異常位置

broker異常位置

注意！這里通過遍歷nameserverlist，在線程池中異步注冊，跟后面的一個小知識點有關。

從源碼中可以分析出，如果有過大的請求的話，應該就是這個requestBody引起，它攜帶了大量topic信息topicConfigWrapper。

但是我們在控制臺上看到當前集群中，只有300+topic（這里其實是一個誤區，最后會解釋），理論上來說是非常小的，為什么會超出容量限制呢？

看了下源碼上下文，并沒有對reqeustBody或者topicConfigWrapper有相關日志的記錄，因此，還是需要arthas來看看了。

（4）arthas定位

直接通過arthas定位實際內存值。

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

查看結果：

內存中實際topic數量

啥玩意？！

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

進一步看看這些topic里面都是些啥？我們調整下arthas的參數-x為4，改變watch變量的深度。

內存中相關topic名稱

發現問題了！

我們看到了大量%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、最佳實踐

（1）定時刪除無效RETRY topic

考慮使用定時任務掃描所有業務topic下的消費組，再根據消費組狀態（狀態為not_online的消費組），拼出對應RETRY topic進行刪除。以上步驟均有開源MQ sdk 的 api 可以調用。

即使后續消費組重新使用，RETRY topic 也會重新創建，不影響消費。

（2）topic總數監控

前面說到在控制臺上看到當前集群中只有300+topic，這里其實是一個誤區，只勾選了NORMAL類型的topic，并沒有注意RETRY、DLQ、SYSTEM類型的topic。

控制臺誤區

而這次幾萬個topic基本都是RETRY類型的。

后續需要添加topic數量監控（包括RETRY類型），防止由于topic數量過多，導致broker注冊失敗。

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。

消費失敗創建RETRY topic

• consumer client 和服務端保持心跳時創建RETRY topic

心跳時創建 retry topic

線下環境的消費組存在大量的臨時測試group，而 RocketMQ會給每個實際存在的消費組創建RETRY topic，導致 RETRY topic 大量膨脹。

（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客戶端的生產者默認重試機制，只對普通消息有作用。對于普通有序消息、嚴格有序消息是沒有作用。

（3）nameserver數據一致性問題

在通過修改啟動參數com.rocketmq.remoting.frameMaxLength進行臨時恢復的時候，發現一個問題：日志恢復了，但是控制臺上卻仍然沒有顯示broker-b。

排查了下發現，由于nameserver有4臺，只重啟了一臺，而控制臺連接訪問的nameserver是另一臺，所以顯示不正確。

通過切換控制臺nameserver地址，就能看到broker-b了。

為什么不同nameserver允許數據不一致呢？

前面在排查的過程中也發現了，broker源碼中通過遍歷nameserverlist，在線程池中異步注冊topic信息到nameserver。

注冊邏輯

而這也體現了RocketM中對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的隊列會存在負載不均衡的問題，以及消費端的重復消費問題，這些問題對消息隊列來說都是可以忍受的，只要最終能保持一致，恢復平衡即可。