1、問題現(xiàn)象

先說明下RocketMQ版本， 4.6.0的老版本了。

線下環(huán)境客戶端啟動會頻繁報錯響應(yīng)超時，導(dǎo)致consumer實例化失敗，無法啟動應(yīng)用。

圖片

2、排查

確認(rèn)線下環(huán)境RocketMQ集群流量、生產(chǎn)消費數(shù)量無異常。

集群gc次數(shù)不多，但是耗時高。（原本監(jiān)控看板異常數(shù)據(jù)缺失，所以少了前面一段）

圖片

master節(jié)點cpu使用率、load極高。

圖片

升配，4c8g升級8c32g，擴大jvm內(nèi)存。

系統(tǒng)指標(biāo)略有下降，但是客戶端異常沒有明顯改善。

只能進一步排查根因，還得上arthas。

thread -n 3

查看cpu高的線程在做什么。

發(fā)現(xiàn)兩個異常線程。

1）一個線程在執(zhí)行AdminBrokerProcessor.queryTopicConsumerByWho()。

圖片

這個是查詢Topic的conusmerGroup信息。

比較奇怪的是，這個請求很頻繁，后來發(fā)現(xiàn)是控制臺應(yīng)用dashboard有個定時任務(wù)，30s查詢一次。

這個請求的耗時主要是在數(shù)組的遍歷處理上，說明內(nèi)存中的數(shù)據(jù)非常大。

圖片

而這個源碼中的offsetTable，就是RocketMQ中保存consumerGroup位點信息的對象。它的key是topic@group拼接的。

圖片

先臨時處理，把dashboard應(yīng)用關(guān)閉了，減少請求。但是效果并不明顯。

2）另一個線程在執(zhí)行定時任務(wù)ConsumerOffsetManager.persist()。

（線程調(diào)用信息忘記截圖了）

這個是RocketMQ集群持久化consumerGroup的offset信息的定時任務(wù)。

圖片

會將整個內(nèi)存對象轉(zhuǎn)化為jsonString寫入磁盤文件中。

這個內(nèi)存對象就是前面提到的offsetTable，就是RocketMQ中保存consumerGroup位點信息的對象。

這里消耗資源多，還是說明我們的內(nèi)存對象非常大。

因為是線下環(huán)境，可靠性要求不高。所以先臨時處理，把定時任務(wù)默認(rèn)配置5s改成50s，減少持久化次數(shù)。

效果顯著，機器cpu、負(fù)載都明顯改善。

好了，現(xiàn)在問題的矛頭都指向了這個offsetTable，那它到底有多大，為什么這么大？

3、定位根因

3.1 直接原因

大對象的定位，一般來說需要dump看看，不過這個對象有點特殊，剛剛也提到了它會被持久化到文件中，所以直接看文件大小和內(nèi)容就行了。

持久化文件的配置路徑，可以看下啟動的conf.properties

storePathRootDir=/usr/local/rocketmq/store1
storePathCommitLog=/usr/local/rocketmq/store1/commitlog
storePathConsumerQueue=/usr/local/rocketmq/store1/consumequeue
storePathIndex=/usr/local/rocketmq/store1/index

在/usr/local/rocketmq/store1目錄下找到config文件夾的consummerOffset.json文件，44M，amazing~

對一個幾十M的對象頻繁序列化和持久化，加上內(nèi)網(wǎng)磁盤比較差，難怪負(fù)載如此高。

（這里截圖是當(dāng)時應(yīng)急時備份的文件，新的文件目前是414K）

3.2 根本原因

為什么這個內(nèi)存對象這么大呢？

查看了下文件內(nèi)容，是RocketMQ中保存consumerGroup位點信息的對象，它的key是topic@group拼接的。

我們發(fā)現(xiàn)大量奇怪的consumerGroup name，跟一個topic聯(lián)合產(chǎn)生了幾千個key。

查看了下內(nèi)部封裝的客戶端代碼，找到了罪魁禍?zhǔn)住?/p>

圖片

線下環(huán)境會根據(jù)小環(huán)境（比如自己起的測試、單測環(huán)境、CI測試環(huán)境等）拼接一個獨立的consumerGroup name。

在線下，每次CI的測試環(huán)境名字會變化，所以導(dǎo)致consumerGroup name數(shù)量急劇膨脹。

4、優(yōu)化

問題找到了，直接的解決方式是刪除文件中無用的consumerGroup name，重啟broker進行加載。

由于是線下環(huán)境，不需要擔(dān)心位點丟失的問題，同時當(dāng)客戶端請求時會自動創(chuàng)建新的位點信息，所以可以考慮直接刪除。

圖片

先停止broker進程（否則會自動落盤內(nèi)存數(shù)據(jù)，創(chuàng)建新的文件），然后重命名相關(guān)文件（用于備份回滾），重新啟動broker進程，讀取空文件加載空對象。

重啟后，各個客戶端在請求集群時，會自動創(chuàng)建訂閱關(guān)系和消費位點記錄，負(fù)載略有升高，然后就恢復(fù)到較低的負(fù)載水位了。

24h的監(jiān)控顯示，優(yōu)化效果顯著，整個機器負(fù)載降低，請求讀寫耗時也顯著降低。

圖片

注意：保存訂閱關(guān)系的subscriptionGroup.json也存在同樣consumerGroup過多導(dǎo)致膨脹的問題，同樣的原因和優(yōu)化方式。默認(rèn)訂閱關(guān)系也是會自動創(chuàng)建的。這里就不展開贅述了。

5、擴展一下

如果類似的問題出在線上怎么辦？

事后來看，類似問題是能夠提前避免的，主要考慮兩個措施：

• 要做好持久化文件（對應(yīng)內(nèi)存對象）大小監(jiān)控，避免出現(xiàn)內(nèi)存大對象。如果發(fā)現(xiàn)異常增長，必須提前排查處理。
• 磁盤要足夠好，使用SSD是基本要求，避免頻繁刷盤導(dǎo)致負(fù)載升高。