溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章給大家分享的是有關如何解決RocketMQ生產環境主題擴分片后遇到的坑的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。
集群信息如下：
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 集群不允許自動創建主題與自動創建消費組。
由于該業務量穩步提升，項目組覺得該主題的隊列數太少，不利于增加消費者來提高其消費能力，故向運維人員提出增加隊列的需求。
運維通過公司自研的消息運維平臺，直接以指定集群的方式為 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
執行效果如圖所示，表示更新成功。
從 RocketMQ 系列可知，RocketMQ 是支持在線 topic 在線擴容機制的，故無需重啟 消息發送者、消息消費者，隨著時間的推移，我們可以查看topic的所有隊列都參與到了消息的負載中，如圖所示：
該 topic 被 5個消費組所訂閱，突然接到通知，其中有兩個消費組反饋，部分隊列的消息沒有被消費，導致下游系統并沒有及時得到處理，引起用戶的注意。
當時到項目組提交到消息組時，我第一反應是先看消費者的隊列，打開該主題的消費情況，如圖所示：
事后諸葛亮：其實這完成是錯誤的，為什么這樣說呢？因為項目組（業務方）已經告知一部分業務未處理，說明肯定有隊列的消息積壓，當根據自己的知識，結合看到的監控頁面做出的判斷與業務方反饋的出現沖突時，一定是自己的判斷出了問題。
正在我們“如火如荼”的認定是項目有問題時，這時另外一個團隊成員提出了一個新的觀點，原來在得到業務方反饋時，他得知同一個主題，被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-7月 的時候，就基本得出結論，是不是擴容時并沒有在新集群上創建訂閱消息，故無法消費消息，后面一查證，果然如此。
然后運維小哥，立馬創建訂閱組，創建方法如圖所示：
潛在原因：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生產環境主題擴分片后遇到的坑”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
