您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關(guān)如何解決RocketMQ生產(chǎn)環(huán)境主題擴分片后遇到的坑的內(nèi)容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
集群信息如下:
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 集群不允許自動創(chuàng)建主題與自動創(chuàng)建消費組。
由于該業(yè)務(wù)量穩(wěn)步提升,項目組覺得該主題的隊列數(shù)太少,不利于增加消費者來提高其消費能力,故向運維人員提出增加隊列的需求。
運維通過公司自研的消息運維平臺,直接以指定集群的方式為 topic 擴容,該運維平臺底層其實使用了RocketMQ 提供的 updateTopic 命令,其命令說明如下:
sh ./mqadmin upateTopic -n 192.168.0.220:9876 -c DefaultCluster -t topic_dw_test_by_order_01 -r 8 -w 8
執(zhí)行效果如圖所示,表示更新成功。
從 RocketMQ 系列可知,RocketMQ 是支持在線 topic 在線擴容機制的,故無需重啟 消息發(fā)送者、消息消費者,隨著時間的推移,我們可以查看topic的所有隊列都參與到了消息的負載中,如圖所示:
該 topic 被 5個消費組所訂閱,突然接到通知,其中有兩個消費組反饋,部分隊列的消息沒有被消費,導(dǎo)致下游系統(tǒng)并沒有及時得到處理,引起用戶的注意。
當時到項目組提交到消息組時,我第一反應(yīng)是先看消費者的隊列,打開該主題的消費情況,如圖所示:
事后諸葛亮:其實這完成是錯誤的,為什么這樣說呢?因為項目組(業(yè)務(wù)方)已經(jīng)告知一部分業(yè)務(wù)未處理,說明肯定有隊列的消息積壓,當根據(jù)自己的知識,結(jié)合看到的監(jiān)控頁面做出的判斷與業(yè)務(wù)方反饋的出現(xiàn)沖突時,一定是自己的判斷出了問題。
正在我們“如火如荼”的認定是項目有問題時,這時另外一個團隊成員提出了一個新的觀點,原來在得到業(yè)務(wù)方反饋時,他得知同一個主題,被5個消費組訂閱,只有其中兩個有問題,那他通過rocketmq-console來找兩者的區(qū)別,找到區(qū)別,找到規(guī)律,就離解決問題的路近了。
他通過對比發(fā)現(xiàn),出問題的消費組只有兩個客戶端在消費(通常生產(chǎn)環(huán)境是4節(jié)點消費),而沒有出現(xiàn)問題的消費組只有4個進程都在處理,即發(fā)現(xiàn)現(xiàn)象:出錯的消費組,并沒有全員參與到消費。正如上面的圖所示:只有其中一個進程在處理8個隊列,另外8個隊列并沒有在消費。
那現(xiàn)在就是要分析為啥topic共有16個隊列,但這里只有1個消費者隊列在消費,另外一個消費者不作為?
首先根據(jù) RocketMQ 消息隊列負載機制,2個消費者,只有1個消費者在消費,并且一個有一個明顯的特點是,只有 broker-a 上的隊列在消費,broker-b 上的隊列一個也沒消費。那這兩個是不是有什么規(guī)律可詢?
正在思考為啥會出現(xiàn)這種現(xiàn)象時,團隊中的另一個同事又在思考是不是集群是不是 broker-b (對應(yīng)我們生產(chǎn)環(huán)境是 broker-c 、broker-d )上的隊列都未消費,是不是這些隊列是在新擴容的機器?擴容的時候是不是沒有把訂閱關(guān)系在新的集群上創(chuàng)建?
提出了疑問,接下來就開始驗證猜想,通過查閱 broker-c、broker-d(對應(yīng)我們生產(chǎn)環(huán)境)在我們系統(tǒng)中創(chuàng)建的時間是 2018-7月 的時候,就基本得出結(jié)論,是不是擴容時并沒有在新集群上創(chuàng)建訂閱消息,故無法消費消息,后面一查證,果然如此。
然后運維小哥,立馬創(chuàng)建訂閱組,創(chuàng)建方法如圖所示:
潛在原因:DefaultCluster 集群進行過一次集群擴容,從原來的一臺消息服務(wù)器( broker-a )額外增加一臺broker服務(wù)器( broker-b ),但擴容的時候并沒有把原先的存在于 broker-a 上的主題、消費組擴容到 broker-b 服務(wù)器。
觸發(fā)原因:接到項目組的擴容需求,將集群隊列數(shù)從4個擴容到8個,這樣該topic就在集群的a、b都會存在8個隊列,但Broker不允許自動創(chuàng)建消費組(訂閱關(guān)系),消費者無法從broker-b上隊列上拉取消息,導(dǎo)致在broker-b隊列上的消息堆積,無法被消費。
解決辦法:運維通過命令,在broker-b上創(chuàng)建對應(yīng)的訂閱消息,問題解決。
經(jīng)驗教訓:集群擴容時,需要同步在集群上的topic.json、subscriptionGroup.json文件。
RocketMQ 理論基礎(chǔ),消費者向 Broker 發(fā)起消息拉取請求時,如果broker上并沒有存在該消費組的訂閱消息時,如果不允許自動創(chuàng)建(autoCreateSubscriptionGroup 設(shè)置為 false),默認為true,則不會返回消息給客戶端,其代碼如下:
問題解決后,團隊內(nèi)部成員也分享了一下他在本次排查問題的處理方法:尋找出現(xiàn)問題的規(guī)律、推斷問題、 然后驗證問題。規(guī)律可以是問題本身的規(guī)律 也可以是和正常對比的差。
感謝各位的閱讀!關(guān)于“如何解決RocketMQ生產(chǎn)環(huán)境主題擴分片后遇到的坑”這篇文章就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。