RocketMQ 主題擴分片后遇到的坑

消息組接到某項目組反饋,topic 在擴容后出現部分隊列無法被消費者,導致消息積壓,影響線上業務?

考慮到該問題是發送在真實的線上環境,為了避免泄密,本文先在筆者的虛擬機中來重現問題。
@(本節目錄)

1、案情回顧

1.1 集群現狀

集群信息如下:
在這里插入圖片描述
例如業務主體名 topic_dw_test_by_order_01 的路由信息如圖所示:
在這里插入圖片描述
當前的消費者信息:
在這里插入圖片描述
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

備注:公司對 topic、消費組進行了嚴格的管控,項目組需要使用時需要向運維人員申請,故 broker 集群不允許自動創建主題與自動創建消費組。

由于該業務量穩步提升,項目組覺得該主題的隊列數太少,不利于增加消費者來提高其消費能力,故向運維人員提出增加隊列的需求。

1.2、RocketMQ 在線擴容隊列

運維通過公司自研的消息運維平臺,直接以指定集群的方式為 topic 擴容,該運維平臺底層其實使用了RocketMQ 提供的 updateTopic 命令,其命令說明如下:
圖片來源于《》RocketMQ技術內幕》
從上圖可以得知可以通過 -c 命令來指定在集群中所有的 broker 上創建隊列,在本例中,將隊列數從 4 設置為 8,具體命令如下:

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

執行效果如圖所示,表示更新成功。
在這里插入圖片描述
我們再來從 rocketmq-console 中來看命令執行后的效果:
在這里插入圖片描述
從上圖可以得知,主題的隊列數已經擴容到了8個,并且在集群的兩臺broker上都創建了隊列。

1.3 消息發送

從 RocketMQ 系列可知,RocketMQ 是支持在線 topic 在線擴容機制的,故無需重啟 消息發送者、消息消費者,隨著時間的推移,我們可以查看topic的所有隊列都參與到了消息的負載中,如圖所示:
在這里插入圖片描述
我們可以清晰的看到,所有的16個隊列(每個 broker 8個隊列)都參與到了消息發送的,運維小哥愉快的完成了topic的擴容。

2、問題暴露

該 topic 被 5個消費組所訂閱,突然接到通知,其中有兩個消費組反饋,部分隊列的消息沒有被消費,導致下游系統并沒有及時處理。

3、問題分析

當時到項目組提交到消息組時,我第一反應是先看消費者的隊列,打開該主題的消費情況,如圖所示:
在這里插入圖片描述
發現隊列數并沒有積壓,備注(由于生產是4主4從,每一個 broker上8個隊列,故總共32個隊列),當時由于比較急,并沒有第一時間發現這個界面,竟然只包含一個消費者,覺得并沒有消息積壓,又由于同一個集群,其他消費組沒有問題,只有兩個消費組有問題,懷疑是應用的問題,就采取了重啟,打印線程棧等方法。

事后諸葛亮:其實這完成是錯誤的,為什么這樣說呢?因為項目組(業務方)已經告知一部分業務未處理,說明肯定有隊列的消息積壓,當根據自己的知識,結合看到的監控頁面做出的判斷與業務方反饋的出現沖突時,一定是自己的判斷出了問題。

正在我們“如火如荼”的認定是項目有問題時,團隊的另一成員提出了自己的觀點,原來在得到業務方反饋時,他得知同一個主題,被5個消費組訂閱,只有其中兩個有問題,那他通過rocketmq-console來找兩者的區別,找到區別,找到規律,就離解決問題的路近了。

他通過對比發現,出問題的消費組只有兩個客戶端在消費(通常生產環境是4節點消費),而沒有出現問題的發現有4個進程都在處理,即發現現象:出錯的消費組,并沒有全員參與到消費。正如上面的圖所示:只有其中一個進程在處理8個隊列,另外8個隊列并沒有在消費。

那現在就是要分析為啥topic共有16個隊列,但這里只有1個消費者隊列在消費,另外一個消費者不作為?

首先根據RocketMQ 消息隊列負載機制,2個消費者,只有1個消費者在消費,并且一個有一個明顯的特點是,只有broker-a上的隊列在消費,broker-b上的隊列一個也沒消費。

正在思考為啥會出現這種現象時,他又在思考是不是集群是不是broker-b(對應我們生產環境是broker-c、broker-d上的隊列都未消費)是新擴容的機器?擴容的時候是不是沒有把訂閱關系在新的集群上創建?提出了疑問,接下來肖工就開始驗證猜想,通過查閱broker-c、broker-d在我們系統中創建的時間是2018-4月的時候,就基本得出結論,擴容時并沒有在新集群上創建訂閱消息,故無法消費消息。

于是運維小哥使用運維工具創建訂閱組,創建方法如圖所示:
在這里插入圖片描述
創建好消費組后,再去查看topic的消費情況時,另外一個消費組也開始處理消息了,如下圖所示:
在這里插入圖片描述

4、問題復盤

潛在原因:DefaultCluster 集群進行過一次集群擴容,從原來的一臺消息服務器( broker-a )額外增加一臺broker服務器( broker-b ),但擴容的時候并沒有把原先的存在于 broker-a 上的主題、消費組擴容到 broker-b 服務器。

觸發原因:接到項目組的擴容需求,將集群隊列數從4個擴容到8個,這樣該topic就在集群的a、b都會存在8個隊列,但Broker不允許自動創建消費組(訂閱關系),消費者無法從broker-b上隊列上拉取消息,導致在broker-b隊列上的消息堆積,無法被消費。

解決辦法:運維通過命令,在broker-b上創建對應的訂閱消息,問題解決。

經驗教訓:集群擴容時,需要同步在集群上的topic.json、subscriptionGroup.json文件。

RocketMQ 理論基礎,消費者向 Broker 發起消息拉取請求時,如果broker上并沒有存在該消費組的訂閱消息時,如果不允許自動創建(autoCreateSubscriptionGroup 設置為 false),默認為true,則不會返回消息給客戶端,其代碼如下:
在這里插入圖片描述
問題解決后,我們團隊的成員也分享了一下他在本次排查問題的處理方法:尋找出現問題的規律、推斷問題、 然后驗證問題。規律可以是問題本身的規律 也可以是和正常對比的差。

如果覺得文章寫的還不錯的話,麻煩幫忙點個贊,謝謝。


作者介紹:丁威,《RocketMQ技術內幕》作者,RocketMQ 社區布道師,公眾號:中間件興趣圈 維護者,目前已陸續發表源碼分析Java集合、Java 并發包(JUC)、Netty、Mycat、Dubbo、RocketMQ、Mybatis等源碼專欄。可以點擊鏈接加入中間件知識星球 ,一起探討高并發、分布式服務架構,交流源碼。

在這里插入圖片描述

posted @ 2019-12-12 22:11  中間件興趣圈  閱讀(...)  評論(...編輯  收藏
四川金7乐历史开奖号码查询