RocketMQ 主題擴(kuò)分片后遇到的坑

消息組接到某項(xiàng)目組反饋，topic 在擴(kuò)容后出現(xiàn)部分隊(duì)列無(wú)法被消費(fèi)者，導(dǎo)致消息積壓，影響線上業(yè)務(wù)？

考慮到該問(wèn)題是發(fā)送在真實(shí)的線上環(huán)境，為了避免泄密，本文先在筆者的虛擬機(jī)中來(lái)重現(xiàn)問(wèn)題。

本節(jié)目錄

1、案情回顧

1.1 集群現(xiàn)狀

1.2、RocketMQ 在線擴(kuò)容隊(duì)列

1.3 消息發(fā)送

2、問(wèn)題暴露

3、問(wèn)題分析

4、問(wèn)題復(fù)盤

1、案情回顧

1.1 集群現(xiàn)狀

集群信息如下：

例如業(yè)務(wù)主體名 topic_dw_test_by_order_01 的路由信息如圖所示：

當(dāng)前的消費(fèi)者信息：

broker 的配置信息如下：

brokerClusterName = DefaultCluster brokerName = broker-a brokerId = 0 deleteWhen = 04 fileReservedTime = 48 brokerRole = ASYNC_MASTER flushDiskType = ASYNC_FLUSH brokerIP1=192.168.0.220 brokerIP2-192.168.0.220 namesrvAddr=192.168.0.221:9876;192.168.0.220:9876 storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog autoCreateTopicEnable=false autoCreateSubscriptionGroup=false

1

2

3

4

5

6

7

8

9

10

11

12

13

14

備注：公司對(duì) topic、消費(fèi)組進(jìn)行了嚴(yán)格的管控，項(xiàng)目組需要使用時(shí)需要向運(yùn)維人員申請(qǐng)，故 broker 集群不允許自動(dòng)創(chuàng)建主題與自動(dòng)創(chuàng)建消費(fèi)組。

由于該業(yè)務(wù)量穩(wěn)步提升，項(xiàng)目組覺(jué)得該主題的隊(duì)列數(shù)太少，不利于增加消費(fèi)者來(lái)提高其消費(fèi)能力，故向運(yùn)維人員提出增加隊(duì)列的需求。

1.2、RocketMQ 在線擴(kuò)容隊(duì)列

運(yùn)維通過(guò)公司自研的消息運(yùn)維平臺(tái)，直接以指定集群的方式為 topic 擴(kuò)容，該運(yùn)維平臺(tái)底層其實(shí)使用了RocketMQ 提供的 updateTopic 命令，其命令說(shuō)明如下：

從上圖可以得知可以通過(guò) -c 命令來(lái)指定在集群中所有的 broker 上創(chuàng)建隊(duì)列，在本例中，將隊(duì)列數(shù)從 4 設(shè)置為 8，具體命令如下：

sh ./mqadmin upateTopic -n 192.168.0.220:9876 -c DefaultCluster -t topic_dw_test_by_order_01 -r 8 -w 8

1

執(zhí)行效果如圖所示，表示更新成功。

我們?cè)賮?lái)從 rocketmq-console 中來(lái)看命令執(zhí)行后的效果：

從上圖可以得知，主題的隊(duì)列數(shù)已經(jīng)擴(kuò)容到了8個(gè)，并且在集群的兩臺(tái)broker上都創(chuàng)建了隊(duì)列。

1.3 消息發(fā)送

從 RocketMQ 系列可知，RocketMQ 是支持在線 topic 在線擴(kuò)容機(jī)制的，故無(wú)需重啟 消息發(fā)送者、消息消費(fèi)者，隨著時(shí)間的推移，我們可以查看topic的所有隊(duì)列都參與到了消息的負(fù)載中，如圖所示：

我們可以清晰的看到，所有的16個(gè)隊(duì)列(每個(gè) broker 8個(gè)隊(duì)列)都參與到了消息發(fā)送的，運(yùn)維小哥愉快的完成了topic的擴(kuò)容。

2、問(wèn)題暴露

該 topic 被 5個(gè)消費(fèi)組所訂閱，突然接到通知，其中有兩個(gè)消費(fèi)組反饋，部分隊(duì)列的消息沒(méi)有被消費(fèi)，導(dǎo)致下游系統(tǒng)并沒(méi)有及時(shí)處理。

3、問(wèn)題分析

當(dāng)時(shí)到項(xiàng)目組提交到消息組時(shí)，我第一反應(yīng)是先看消費(fèi)者的隊(duì)列，打開(kāi)該主題的消費(fèi)情況，如圖所示：

發(fā)現(xiàn)隊(duì)列數(shù)并沒(méi)有積壓，備注（由于生產(chǎn)是4主4從，每一個(gè) broker上8個(gè)隊(duì)列，故總共32個(gè)隊(duì)列），當(dāng)時(shí)由于比較急，并沒(méi)有第一時(shí)間發(fā)現(xiàn)這個(gè)界面，竟然只包含一個(gè)消費(fèi)者，覺(jué)得并沒(méi)有消息積壓，又由于同一個(gè)集群，其他消費(fèi)組沒(méi)有問(wèn)題，只有兩個(gè)消費(fèi)組有問(wèn)題，懷疑是應(yīng)用的問(wèn)題，就采取了重啟，打印線程棧等方法。

事后諸葛亮：其實(shí)這完成是錯(cuò)誤的，為什么這樣說(shuō)呢？因?yàn)轫?xiàng)目組（業(yè)務(wù)方）已經(jīng)告知一部分業(yè)務(wù)未處理，說(shuō)明肯定有隊(duì)列的消息積壓，當(dāng)根據(jù)自己的知識(shí)，結(jié)合看到的監(jiān)控頁(yè)面做出的判斷與業(yè)務(wù)方反饋的出現(xiàn)沖突時(shí)，一定是自己的判斷出了問(wèn)題。

正在我們“如火如荼”的認(rèn)定是項(xiàng)目有問(wèn)題時(shí)，團(tuán)隊(duì)的另一成員提出了自己的觀點(diǎn)，原來(lái)在得到業(yè)務(wù)方反饋時(shí)，他得知同一個(gè)主題，被5個(gè)消費(fèi)組訂閱，只有其中兩個(gè)有問(wèn)題，那他通過(guò)rocketmq-console來(lái)找兩者的區(qū)別，找到區(qū)別，找到規(guī)律，就離解決問(wèn)題的路近了。

他通過(guò)對(duì)比發(fā)現(xiàn)，出問(wèn)題的消費(fèi)組只有兩個(gè)客戶端在消費(fèi)（通常生產(chǎn)環(huán)境是4節(jié)點(diǎn)消費(fèi)），而沒(méi)有出現(xiàn)問(wèn)題的發(fā)現(xiàn)有4個(gè)進(jìn)程都在處理，即發(fā)現(xiàn)現(xiàn)象：出錯(cuò)的消費(fèi)組，并沒(méi)有全員參與到消費(fèi)。正如上面的圖所示：只有其中一個(gè)進(jìn)程在處理8個(gè)隊(duì)列，另外8個(gè)隊(duì)列并沒(méi)有在消費(fèi)。

那現(xiàn)在就是要分析為啥topic共有16個(gè)隊(duì)列，但這里只有1個(gè)消費(fèi)者隊(duì)列在消費(fèi)，另外一個(gè)消費(fèi)者不作為？

首先根據(jù)RocketMQ 消息隊(duì)列負(fù)載機(jī)制，2個(gè)消費(fèi)者，只有1個(gè)消費(fèi)者在消費(fèi)，并且一個(gè)有一個(gè)明顯的特點(diǎn)是，只有broker-a上的隊(duì)列在消費(fèi)，broker-b上的隊(duì)列一個(gè)也沒(méi)消費(fèi)。

正在思考為啥會(huì)出現(xiàn)這種現(xiàn)象時(shí)，他又在思考是不是集群是不是broker-b(對(duì)應(yīng)我們生產(chǎn)環(huán)境是broker-c、broker-d上的隊(duì)列都未消費(fèi))是新擴(kuò)容的機(jī)器？擴(kuò)容的時(shí)候是不是沒(méi)有把訂閱關(guān)系在新的集群上創(chuàng)建？提出了疑問(wèn)，接下來(lái)肖工就開(kāi)始驗(yàn)證猜想，通過(guò)查閱broker-c、broker-d在我們系統(tǒng)中創(chuàng)建的時(shí)間是2018-4月的時(shí)候，就基本得出結(jié)論，擴(kuò)容時(shí)并沒(méi)有在新集群上創(chuàng)建訂閱消息，故無(wú)法消費(fèi)消息。

于是運(yùn)維小哥使用運(yùn)維工具創(chuàng)建訂閱組，創(chuàng)建方法如圖所示：

創(chuàng)建好消費(fèi)組后，再去查看topic的消費(fèi)情況時(shí)，另外一個(gè)消費(fèi)組也開(kāi)始處理消息了，如下圖所示：

4、問(wèn)題復(fù)盤

潛在原因：DefaultCluster 集群進(jìn)行過(guò)一次集群擴(kuò)容，從原來(lái)的一臺(tái)消息服務(wù)器( broker-a )額外增加一臺(tái)broker服務(wù)器( broker-b )，但擴(kuò)容的時(shí)候并沒(méi)有把原先的存在于 broker-a 上的主題、消費(fèi)組擴(kuò)容到 broker-b 服務(wù)器。

觸發(fā)原因：接到項(xiàng)目組的擴(kuò)容需求，將集群隊(duì)列數(shù)從4個(gè)擴(kuò)容到8個(gè)，這樣該topic就在集群的a、b都會(huì)存在8個(gè)隊(duì)列，但Broker不允許自動(dòng)創(chuàng)建消費(fèi)組（訂閱關(guān)系），消費(fèi)者無(wú)法從broker-b上隊(duì)列上拉取消息，導(dǎo)致在broker-b隊(duì)列上的消息堆積，無(wú)法被消費(fèi)。

解決辦法：運(yùn)維通過(guò)命令，在broker-b上創(chuàng)建對(duì)應(yīng)的訂閱消息，問(wèn)題解決。

經(jīng)驗(yàn)教訓(xùn)：集群擴(kuò)容時(shí)，需要同步在集群上的topic.json、subscriptionGroup.json文件。

RocketMQ 理論基礎(chǔ)，消費(fèi)者向 Broker 發(fā)起消息拉取請(qǐng)求時(shí)，如果broker上并沒(méi)有存在該消費(fèi)組的訂閱消息時(shí)，如果不允許自動(dòng)創(chuàng)建(autoCreateSubscriptionGroup 設(shè)置為 false)，默認(rèn)為true，則不會(huì)返回消息給客戶端，其代碼如下：

問(wèn)題解決后，我們團(tuán)隊(duì)的成員也分享了一下他在本次排查問(wèn)題的處理方法：尋找出現(xiàn)問(wèn)題的規(guī)律、推斷問(wèn)題、 然后驗(yàn)證問(wèn)題。規(guī)律可以是問(wèn)題本身的規(guī)律 也可以是和正常對(duì)比的差。

如果覺(jué)得文章寫(xiě)的還不錯(cuò)的話，麻煩幫忙點(diǎn)個(gè)贊，謝謝。

見(jiàn)文如面，我是威哥，熱衷于成體系剖析JAVA主流中間件，關(guān)注公眾號(hào)『中間件興趣圈』，回復(fù)專欄可獲取成體系專欄導(dǎo)航，回復(fù)資料可以獲取筆者的學(xué)習(xí)思維導(dǎo)圖。

Kafka 大數(shù)據(jù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。