面試時候被問到“RocketMQ 消息堆積怎么辦”其實(shí)真正想聽的未必是標(biāo)準(zhǔn)操作而是你有沒有獨(dú)立處理過線上壓測和真實(shí)故障。因?yàn)橄⒍逊e背后的坑太典型了消費(fèi)速度跟不上、隊(duì)列并發(fā)配錯、死信沒人管、監(jiān)控看不到積壓趨勢。這篇文章不打算背八股我會把排查思路、應(yīng)急手段、治本方案、還有我實(shí)際踩過的坑全部攤開講一遍適合正在準(zhǔn)備面試的研發(fā)同學(xué)也適合已經(jīng)上了 RocketMQ 但還沒遭過大堵車的運(yùn)維和架構(gòu)師。先說一下我的態(tài)度消息堆積本身不可怕可怕的是堆積之后你還在亂加機(jī)器。很多人一看到積壓數(shù)字變紅第一反應(yīng)就是擴(kuò)容消費(fèi)者實(shí)例結(jié)果加了 20 臺上去積壓一點(diǎn)沒降。為什么因?yàn)?RocketMQ 的消費(fèi)并行度根本不由機(jī)器數(shù)量決定隊(duì)列數(shù)量才是上限。這些底層機(jī)制不搞明白后續(xù)所有操作都是盲人摸象。這篇內(nèi)容從堆積發(fā)生的原理講起再給出一套完整的排查命令和監(jiān)控指標(biāo)然后按“應(yīng)急、優(yōu)化、擴(kuò)容、治本”四個層次拆解解決方案最后附上真實(shí)案例復(fù)盤和日常預(yù)防體系。你可以把它當(dāng)作一張消息堆積處理的地圖線上出了狀況照著走至少不會慌。1. 消息堆積的本質(zhì)先搞清楚消息積壓在哪里1.1 一條消息從生產(chǎn)到消費(fèi)堆積到底發(fā)生在哪個環(huán)節(jié)我特別喜歡用一個比喻來解釋 RocketMQ 的消息流轉(zhuǎn)生產(chǎn)者是擰開的水龍頭消費(fèi)者是下水道地漏Broker 是中間的蓄水池。正常情況下水龍頭進(jìn)水速度和地漏排水速度差不多水池水位穩(wěn)定一旦進(jìn)水速度超過排水速度或者地漏本身堵了水位就開始漲。RocketMQ 里的“水位”就是消費(fèi)位點(diǎn)ConsumerOffset和最大位點(diǎn)MaxOffset的差值也就是我們常說的積壓量。你手上有這么一條鏈路Producer 把消息寫到 BrokerBroker 把消息順序追加到 CommitLog同時按照 Topic 隊(duì)列生成邏輯索引 ConsumeQueue然后等消費(fèi)者來拉取。消息一旦進(jìn)了 CommitLog它就穩(wěn)穩(wěn)地躺在 Broker 磁盤上不存在“弄丟”的可能唯一的問題是消費(fèi)者有沒有及時把它消費(fèi)掉并提交位點(diǎn)。所以嚴(yán)格來說消息堆積不是消息在 Producer 端堵住而是 Broker 里的消息沒有被消費(fèi)者按照正常速度取走屬于消費(fèi)側(cè)問題。這里有一個很多人容易忽略的細(xì)節(jié)Broker 上的“積壓”其實(shí)分兩塊一塊是正常業(yè)務(wù) Topic 下每個隊(duì)列里未被消費(fèi)的消息另一塊是消費(fèi)失敗后進(jìn)入的重試隊(duì)列和死信隊(duì)列。當(dāng)你打開 Dashboard 看某個消費(fèi)組的積壓數(shù)量時統(tǒng)計(jì)口徑通常是所有隊(duì)列位點(diǎn)差值的總和但如果業(yè)務(wù)里消費(fèi)失敗率很高你會發(fā)現(xiàn)重試隊(duì)列里其實(shí)還壓著一批“隱形積壓”主隊(duì)列看著還好實(shí)際消息已經(jīng)從主隊(duì)列挪到重試隊(duì)列了消費(fèi)滯后依舊無法緩解。這個視角很重要因?yàn)楹芏嗯挪槭侄蔚谝徊蕉级⒅麝?duì)列結(jié)果忽略了重試和死信。還要注意Broker 側(cè)每個 Topic 默認(rèn)會劃分成多個隊(duì)列比如默認(rèn)創(chuàng)建 4 個寫隊(duì)列和 4 個讀隊(duì)列。消息會按照選擇策略分配到不同隊(duì)列里而消費(fèi)端同一個消費(fèi)組的消費(fèi)者實(shí)例會瓜分這些隊(duì)列。水位到底是均勻上漲還是某個隊(duì)列單獨(dú)暴漲這是判斷瓶頸位置的第一張圖。1.2 消費(fèi)并發(fā)模型和重試機(jī)制決定了你能怎么處理堆積RocketMQ 的客戶端雖然叫 PushConsumer但底層其實(shí)是長輪詢拉取模式。消費(fèi)者啟動后每個實(shí)例會啟動拉取線程向 Broker 拉取一批消息然后提交到消費(fèi)線程池里執(zhí)行業(yè)務(wù)邏輯處理成功就上報(bào)位點(diǎn)處理失敗就會觸發(fā)重試。這個“拉一批、處理一批、上報(bào)位點(diǎn)”的過程有個關(guān)鍵含義消費(fèi)并行度是由隊(duì)列數(shù)量和消費(fèi)線程數(shù)共同決定的但隊(duì)列數(shù)量是天花板。我打個比方隊(duì)列就像是傳送帶上的工位每個工位同時只能站一個工人消費(fèi)者實(shí)例就是工人數(shù)量。傳送帶只有 8 條你哪怕喊來 100 個工人同一時刻能上手處理的也只有 8 條傳送帶上的 8 份工作。在 RocketMQ 這里一個隊(duì)列同一時刻只分配到一個消費(fèi)者實(shí)例一個消費(fèi)者實(shí)例內(nèi)部才能多個線程并行消費(fèi)它擁有的隊(duì)列所以消費(fèi)者實(shí)例再多的只要 Topic 隊(duì)列數(shù)不增加并行度就上不去。這就是“加了 20 臺機(jī)器但積壓紋絲不動”的根本原因。重試機(jī)制也得拎出來說清楚。業(yè)務(wù)消費(fèi)拋異常時RocketMQ 會按延遲級別重試默認(rèn) 16 次間隔從 1 秒逐步拉長到最長 10 分鐘以上。重試期間消息不在原隊(duì)列里而是進(jìn)入 ConsumerGroup 對應(yīng)的重試隊(duì)列。如果重試全失敗消息會進(jìn)入死信隊(duì)列等待人工處理。這套機(jī)制保護(hù)了消息不丟但也帶來一個副作用如果業(yè)務(wù)邏輯處于“一直失敗”狀態(tài)重試隊(duì)列會不斷吞噬積壓主隊(duì)列積壓數(shù)字看著上漲不明顯但消費(fèi)位點(diǎn)就是不動。所以排查積壓問題時重試次數(shù)、消費(fèi)失敗率、死信隊(duì)列積壓三項(xiàng)必須一起看任何一個異常都可能導(dǎo)致“水龍頭正常、地漏卻堵了”。了解完這些底層機(jī)制你就能理解為什么我不主張一上來就重啟服務(wù)。重啟消費(fèi)者只是讓進(jìn)程恢復(fù)那些已經(jīng)掛在 Broker 上的消息依然在消費(fèi)邏輯沒變重啟一百遍也消不完。正確做法是先分清是“水龍頭放水變快”還是“地漏排水變慢”再決定下一步動作。2. 排查消息堆積的完整思路從監(jiān)控到定位瓶頸2.1 第一步先確認(rèn)這是不是真的堆積線上遇到積壓告警先別急著操作第一步是確認(rèn)告警本身是否可靠。所謂“偽堆積”指的是消費(fèi)位點(diǎn)其實(shí)在正常推進(jìn)但由于監(jiān)控系統(tǒng)數(shù)據(jù)延遲、消費(fèi)組名寫錯、Dashboard 統(tǒng)計(jì)口徑異常等原因展示出一個虛高的積壓數(shù)字。我在實(shí)際工作中就見過監(jiān)控系統(tǒng)每 5 分鐘拉一次 Broker 數(shù)據(jù)在消費(fèi)位點(diǎn)尚未刷新到最新時算出來的差值偏大誤報(bào)了好幾次。最原始也最可靠的辦法是用命令行工具查看真實(shí)位點(diǎn)。找到你部署 RocketMQ 的機(jī)器直接執(zhí)行# 查看某個消費(fèi)組的消費(fèi)進(jìn)度的簡單命令具體參數(shù)以你安裝的版本為準(zhǔn) mqadmin consumerProgress -g 你的消費(fèi)組名 -n 你的nameserver地址輸出里會列出每個 Topic 每個隊(duì)列的最大位點(diǎn)、消費(fèi)位點(diǎn)以及兩者差值。如果差值是 0 或者在一個很小的區(qū)間內(nèi)波動說明消費(fèi)速度是跟得上的當(dāng)前告警大概率是誤報(bào)如果差值持續(xù)變大這個積壓才是真積壓。同時還要確認(rèn)消費(fèi)組名字別搞錯。RocketMQ 里消費(fèi)進(jìn)度是按消費(fèi)組維度存儲的你明明有一套新的消費(fèi)者示例在跑但如果 group 名和監(jiān)控面板里配的不是同一個監(jiān)控自然顯示積壓原消費(fèi)組卻已經(jīng)把消息消費(fèi)完了。這種低級問題在微服務(wù)化改造后特別常見不同團(tuán)隊(duì)各建一套 group 卻不更新監(jiān)控配置。此外建議一上來就把三個面板拉出來看實(shí)時積壓量、積壓變化趨勢、消費(fèi) TPS。積壓量是存量變化趨勢是速度消費(fèi) TPS 是能力。只看積壓量會誤判嚴(yán)重程度比如積壓 10 萬條但消費(fèi) TPS 有 5000理論上 20 秒就能追平真不用慌反之積壓只有 5000 條但消費(fèi) TPS 為 0那才叫真故障。2.2 判斷“能消化”還是“消化不動”消費(fèi)能力和耗時是關(guān)鍵確認(rèn)積壓真實(shí)之后先分清楚一個核心問題當(dāng)前消費(fèi)能力有沒有在正常輸出如果消費(fèi) TPS 接近正常水平只是生產(chǎn)峰值更高導(dǎo)致積壓這是“流量壓差型”積壓處理起來相對容易如果消費(fèi) TPS 掉到 0 或者極低這是“消費(fèi)故障型”積壓必須立刻找消費(fèi)端哪里出了問題。判斷消費(fèi)能力用命令行工具看消費(fèi)狀態(tài)同時觀察消費(fèi)者進(jìn)程本身運(yùn)行是否正常。消費(fèi)狀態(tài)里可以看到每個客戶端實(shí)例的消費(fèi)位點(diǎn)、拉取位點(diǎn)、隊(duì)列分配情況以及在線的消費(fèi)者列表。如果某個實(shí)例遲遲沒有上報(bào)位點(diǎn)同時隊(duì)列分配集中在剩余幾個實(shí)例上大概率是某個消費(fèi)者實(shí)例已經(jīng)掛掉或者卡死觸發(fā)了隊(duì)列的重新分配Rebalance而新分配的實(shí)例還沒來得及追上。接下來要確認(rèn)消費(fèi)耗時。一個常見的排查姿勢是在業(yè)務(wù)代碼里給消費(fèi)邏輯加上埋點(diǎn)日志打印單條消息的處理耗時。別小看這個動作很多積壓的根源就是消費(fèi)邏輯里某個環(huán)節(jié)從平均 50ms 漲到了 800ms比如下游數(shù)據(jù)庫出現(xiàn)慢查詢、Redis 熱點(diǎn)鍵超時、外部 RPC 接口抖動。耗時一長線程池被占滿新消息拉出來了也排不上隊(duì)整體消費(fèi) TPS 自然往下掉。這里我分享一個我自己的排查習(xí)慣先把消費(fèi)線程池核心數(shù)和最大數(shù)、當(dāng)前活躍線程數(shù)、隊(duì)列長度這些指標(biāo)用 JMX 或可視化工具拉出來看一眼。如果活躍線程數(shù)始終等于最大線程數(shù)并且阻塞隊(duì)列一直有等待任務(wù)說明你的消費(fèi)線程已經(jīng)被卡住了消費(fèi)耗時變大是果線程耗盡才是表象。這時再去逐層排查消費(fèi)邏輯里是什么拖慢了速度。我遇到過最典型的一次是業(yè)務(wù)方在消費(fèi)邏輯里同步調(diào)了下游的“用戶等級判定”接口平時就 30ms 左右結(jié)果那天數(shù)據(jù)庫連接池被打滿接口耗時漲到 5 秒消費(fèi)線程很快全部卡住。最后那個系統(tǒng)的積壓從 0 漲到 30 萬只用了不到半小時。所以排查積壓一定要先看消費(fèi)鏈路上游的健康度而不是一上來就調(diào) RocketMQ 參數(shù)。2.3 逐個環(huán)節(jié)掃描實(shí)例、隊(duì)列、消費(fèi)組一個都不漏確認(rèn)消費(fèi)能力有問題之后就開始做系統(tǒng)性掃描我習(xí)慣按“實(shí)例層、隊(duì)列層、消費(fèi)組層”三步走。實(shí)例層排查消費(fèi)者進(jìn)程的資源占用和健康度CPU 利用率是否長期跑滿、JVM GC 是否頻繁、線程池有沒有大量拒絕任務(wù)、機(jī)器網(wǎng)絡(luò)吞吐有沒有異常。這一步可以用 Arthas 或者 jstack 直接抓線程?？纯聪M(fèi)線程到底阻塞在哪個調(diào)用點(diǎn)上。我得提醒一句很多開發(fā)者會忽略機(jī)器網(wǎng)絡(luò)本身消費(fèi)組所在機(jī)器的帶寬打滿也會讓拉取速度急劇下降這種積壓你光看業(yè)務(wù)日志完全看不出來。隊(duì)列層排查從 Broker 側(cè)看每個 Topic 隊(duì)列的積壓分布。用命令或者 Dashboard 把每個隊(duì)列的位點(diǎn)差單獨(dú)列出來如果積壓均勻分布在所有隊(duì)列大概率是整體消費(fèi)能力不夠如果積壓集中在一兩個隊(duì)列就要考慮消息分配是否不均勻或者有沒有某個隊(duì)列對應(yīng)的消費(fèi)者實(shí)例出問題。我在實(shí)戰(zhàn)里見過最離譜的情況是某個消費(fèi)者實(shí)例所在機(jī)器磁盤滿了ReBalance 之后它的隊(duì)列遲遲分配不出去結(jié)果積壓全堆在少數(shù)隊(duì)列上。消費(fèi)組層排查要看有沒有多個消費(fèi)者實(shí)例訂閱了同一個消費(fèi)組但它們實(shí)際處理邏輯卻不一樣。由于 RocketMQ 中同一個消費(fèi)組內(nèi)消息會被負(fù)載均衡地分到所有實(shí)例上如果某個實(shí)例的代碼邏輯有問題比如它消費(fèi)失敗率高或者處理特別慢整體消費(fèi)能力就會被這個“木桶短板”拉低。這類問題尤其容易出現(xiàn)在沒有做灰度隔離、新老版本共存一段時間的系統(tǒng)里。3. 解決消息堆積的四個層次優(yōu)化、擴(kuò)容、兜底、治本3.1 消費(fèi)端優(yōu)化先把單條消息的消費(fèi)速度提上去在擴(kuò)容和重置位點(diǎn)之前我強(qiáng)烈建議先做一輪消費(fèi)端優(yōu)化因?yàn)橥瑯右粭l消息你要是能把它處理得更快積壓自然就消化得快。第一個可以動的是消費(fèi)線程數(shù)。RocketMQ 的 DefaultMQPushConsumer 默認(rèn)消費(fèi)線程數(shù)在 20 左右你可以按實(shí)際 CPU 核數(shù)和業(yè)務(wù)邏輯調(diào)整。設(shè)置方式是在代碼里指定consumer.setConsumeThreadMin(20); consumer.setConsumeThreadMax(64);注意線程數(shù)不是越大越好如果業(yè)務(wù)邏輯里有鎖、有數(shù)據(jù)庫行鎖競爭、有外部接口阻塞線程數(shù)拉高反而會增加等待和上下文切換TPS 未必上行。一般建議先從 30 到 50 之間開始調(diào)整觀察消費(fèi) TPS 和 CPU 使用率找到一個拐點(diǎn)。第二個是批量消費(fèi)。RocketMQ 的 DefaultMQPushConsumer 默認(rèn)一次拉取的消息數(shù)不多如果你每條消息的處理邏輯都包含網(wǎng)絡(luò) IO可以考慮開啟批量消費(fèi)。設(shè)置參數(shù)是consumer.setConsumeMessageBatchMaxSize(8);批量消費(fèi)適合那種可以攢一批再處理的消息類型比如批量寫數(shù)據(jù)庫、批量調(diào)批量接口。但如果一條消息本身的處理就涉及事務(wù)性操作批量反而難處理因?yàn)槟阋约罕ＷC批內(nèi)消息部分失敗時的重試語義。這一步?jīng)]有萬金油需要按業(yè)務(wù)形態(tài)取舍。第三個優(yōu)化點(diǎn)才是重點(diǎn)消費(fèi)邏輯本身。把消費(fèi)邏輯里的外部 RPC 調(diào)用從串行改成并行能走本地緩存的一定要走緩存能合并到批量查詢的不要一條一條查數(shù)據(jù)庫能異步化的非關(guān)鍵步驟丟到獨(dú)立線程池里執(zhí)行不讓它卡消費(fèi)主流程。很多時候消費(fèi)耗時的瓶頸根本不在 RocketMQ 上而是業(yè)務(wù)代碼自己把鏈路拉長了。你要記住消息積壓只是表象消費(fèi)端處理能力才是真正的核心瓶頸。3.2 擴(kuò)容的正確姿勢別只盯著機(jī)器數(shù)量消費(fèi)端優(yōu)化做完還不夠如果積壓量很大比如幾十萬上百萬條光靠提高單機(jī)消費(fèi)速度可能需要幾個小時才能消化這時候就得考慮擴(kuò)容。但擴(kuò)容前先記住一句話RocketMQ 的消費(fèi)并行度由隊(duì)列數(shù)量決定機(jī)器數(shù)量只影響單臺機(jī)器上的并發(fā)線程數(shù)機(jī)器再多也突破不了隊(duì)列總數(shù)的上限。具體來說如果你 Topic 的讀隊(duì)列數(shù)是 8當(dāng)前有 8 臺消費(fèi)者實(shí)例那么每臺實(shí)例各消費(fèi) 1 個隊(duì)列擴(kuò)容到 16 臺實(shí)例也只能讓 8 臺實(shí)例干活剩下 8 臺不會有任何消費(fèi)行為。所以擴(kuò)容集群前先確認(rèn) Topic 的隊(duì)列數(shù)量是否足夠。查看和修改隊(duì)列數(shù)的辦法是利用管理工具或者 Dashboard 更新 Topic 配置把讀隊(duì)列數(shù)從 8 調(diào)整到 16、32甚至更多。但是有一個極其重要的坑如果業(yè)務(wù)里用到了順序消息你就不能隨意改動隊(duì)列數(shù)。因?yàn)轫樞蛳⒁蕾囅㈥?duì)列選擇規(guī)則比如按業(yè)務(wù)主鍵 hash 到固定隊(duì)列一旦隊(duì)列數(shù)變化hash 分布就會重新洗牌原來同一個業(yè)務(wù)鍵的消息可能被分配到不同隊(duì)列破壞局部順序。這種情況下擴(kuò)容消費(fèi)者實(shí)例并不能提升并行度因?yàn)橥粋€隊(duì)列同時只允許一個消費(fèi)者實(shí)例消費(fèi)而順序消息又不能讓多個線程并發(fā)消費(fèi)同一個隊(duì)列。遇到這種場景更合理的方案是業(yè)務(wù)層面拆分 Topic把不同業(yè)務(wù)域的訂單消息拆到不同 Topic每個 Topic 可以有獨(dú)立的隊(duì)列數(shù)和消費(fèi)者實(shí)例這樣既保證業(yè)務(wù)內(nèi)順序又提升了鏈路整體并行度。還要注意擴(kuò)容消費(fèi)實(shí)例之后一定要重啟或者觸發(fā) rebalance讓新實(shí)例能真正分到隊(duì)列。很多團(tuán)隊(duì)給容器平臺擴(kuò)容了 Pod 數(shù)量但因?yàn)?RocketMQ 客戶端實(shí)例注冊有延遲新實(shí)例沒有及時拿到隊(duì)列分配舊實(shí)例依然在扛壓力。通過 consumerStatus 命令可以確認(rèn)每個實(shí)例當(dāng)前分到的隊(duì)列數(shù)量看到分配均衡后再下結(jié)論。3.3 緊急兜底重置位點(diǎn)、死信處理和臨時降級有些積壓場景時間緊、任務(wù)重比如大促時積壓了幾百萬條消息但業(yè)務(wù)要求 10 分鐘之內(nèi)恢復(fù)這時候免不了要做一些“非常規(guī)”操作。必須說清楚這類操作有副作用一定要在確認(rèn)業(yè)務(wù)可接受、并且有人審批的情況下才能執(zhí)行。最直接的兜底操作是重置消費(fèi)位點(diǎn)也就是把消費(fèi)組的消費(fèi)進(jìn)度直接調(diào)到最新位點(diǎn)。這樣積壓的歷史消息就不消費(fèi)了相當(dāng)于放棄了舊消息只從當(dāng)前時間點(diǎn)往后消費(fèi)新消息。具體命令# 重置消費(fèi)位點(diǎn)到一個較早或較新的時間點(diǎn)需要用時間戳單位毫秒 mqadmin resetOffsetByTime -g 消費(fèi)組名 -t Topic名 -s 當(dāng)前時間戳 -n nameserver地址這個操作一旦執(zhí)行消費(fèi)進(jìn)度就跳到指定時間點(diǎn)歷史消息不會進(jìn)入正常消費(fèi)流程。所以你一定要問清楚業(yè)務(wù)方這些積壓消息里有沒有必須處理的訂單、扣款、補(bǔ)償類消息如果丟棄會造成數(shù)據(jù)不一致那絕對不能盲目跳過。我見過有的團(tuán)隊(duì)為了快速恢復(fù)系統(tǒng)直接 reset 了一大堆交易消息事后發(fā)現(xiàn)大量訂單狀態(tài)沒更新只能靠人工跑批補(bǔ)償折騰了整整兩天。死信隊(duì)列的處理也需要配套進(jìn)行。積壓期間很多消息會經(jīng)歷 16 次重試最終進(jìn)入死信隊(duì)列這些消息如果業(yè)務(wù)上還有價值就要寫一個專門掃死信隊(duì)列的程序把消息撈出來重新投遞到正常 Topic 或者直接調(diào)用補(bǔ)償接口。我在后面會專門講到死信排查這里想強(qiáng)調(diào)的是死信不是終點(diǎn)務(wù)必清零。臨時降級指的是在消費(fèi)端代碼上做個方案開關(guān)把非核心邏輯臨時關(guān)閉。比如消費(fèi)訂單消息時原本需要同步調(diào)用積分服務(wù)、短信服務(wù)、審計(jì)服務(wù)在堆積嚴(yán)重時只保留訂單狀態(tài)更新這個核心動作其余全部降級或異步化。這種做法能迅速把單條消息的處理耗時降下來相當(dāng)于給地漏臨時加大排水口徑先把水位降下去等活動峰值過去再恢復(fù)完整鏈路。這個思路在電商大促場景下非常常用前提是業(yè)務(wù)方同意非核心邏輯的延時執(zhí)行并且有補(bǔ)償機(jī)制。3.4 治本容量規(guī)劃、隔離與鏈路治理應(yīng)急處理完更要回頭思考一個問題為什么這次會堆積如果只是流量突然翻倍那下一次流量再翻倍怎么辦消息堆積治理的治本方案其實(shí)就是容量規(guī)劃和系統(tǒng)性隔離。容量規(guī)劃層面要對核心 Topic 做生產(chǎn)流量峰值的預(yù)估并按照這個峰值預(yù)留消費(fèi)能力。一般建議消費(fèi)端的處理能力要比預(yù)估峰值高出 30% 到 50%再加上彈性擴(kuò)容的能力保證突發(fā)流量增長時能快速補(bǔ)充消費(fèi)實(shí)例。這里我推薦定期對消費(fèi)端做壓測用壓測工具向指定 Topic 灌入平時流量的 2 到 3 倍消息觀察消費(fèi) TPS、積壓曲線和消費(fèi)耗時把每個業(yè)務(wù)鏈路的容量基準(zhǔn)摸出來。有了基線后面再談擴(kuò)容和告警閾值才有參考意義。隔離層面我提倡把一個大的 Topic 按業(yè)務(wù)重要性拆開。比如訂單系統(tǒng)可以拆成“訂單核心狀態(tài)消息 Topic”和“訂單營銷通知消息 Topic”前者消費(fèi)端配備了更高的機(jī)器規(guī)格和更完善的監(jiān)控后者消費(fèi)端即便堆積也不影響主流程。這種拆分的本質(zhì)是把資源隔離和治理邊界劃清楚避免一條慢業(yè)務(wù)拖垮所有消費(fèi)組。你如果做過 RocketMQ 選型對比就會發(fā)現(xiàn)類似這種基于 Topic 進(jìn)行業(yè)務(wù)隔離的能力RocketMQ 相比另一些消息隊(duì)列更靈活這也是當(dāng)時很多人選它的原因之一。鏈路治理層面要把消費(fèi)端對下游的依賴做分級。能降級的降級能異步的異步能做成輪詢補(bǔ)償?shù)木蛣e用同步強(qiáng)依賴。我在一家公司做技術(shù)負(fù)責(zé)人那會兒團(tuán)隊(duì)約定所有消費(fèi)邏輯不能超過三個依賴調(diào)用每多一個依賴就得寫一個獨(dú)立降級方案。這個約定后來挽救了無數(shù)個大促夜因?yàn)檎嬲鸱e壓的從來不是消息中間件自己而是消費(fèi)邏輯里那些脆弱的遠(yuǎn)程調(diào)用。4. 實(shí)戰(zhàn)案例復(fù)盤和日常預(yù)防體系4.1 一次大促消息堆積處置流程復(fù)盤講一個很典型的場景。某次大促預(yù)熱期訂單系統(tǒng)流量瞬間翻了三倍用 Dashboard 看消息積壓數(shù)字從個位數(shù)一路漲到近 80 萬消費(fèi)組的消費(fèi) TPS 卻在持續(xù)探底。當(dāng)時負(fù)責(zé)的同學(xué)第一反應(yīng)是給消費(fèi)者集群擴(kuò)容但擴(kuò)容完 15 分鐘積壓不但沒降反而還在漲。后來排查發(fā)現(xiàn)Topic 隊(duì)列數(shù)只有 8擴(kuò)容后的 20 個應(yīng)用實(shí)例有一大半是空閑的真正干活的只有 8 個實(shí)例。處置過程我盡量還原大家看這個順序先看 Dashboard 確認(rèn)積壓分布發(fā)現(xiàn)每個隊(duì)列積壓都很高排除單個隊(duì)列異常再查消費(fèi)者實(shí)例狀態(tài)發(fā)現(xiàn)部分實(shí)例 CPU 使用率長時間超過 80%消費(fèi)線程大量阻塞隨后抓線程棧定位到消費(fèi)邏輯中調(diào)用的庫存服務(wù)接口耗時飆升單次調(diào)用從 50ms 漲到了 2 秒以上。這時候做兩件事一是在配置中心打開降級開關(guān)讓消費(fèi)端跳過幾個非核心的校驗(yàn)邏輯和營銷同步二是把 Topic 隊(duì)列數(shù)提升到 32然后給消費(fèi)者集群擴(kuò)容觸發(fā)一次平滑 rebalance。降級開關(guān)一打開單條消息耗時就降下來了消費(fèi) TPS 從 200 漲到接近 1500。隊(duì)列擴(kuò)容后32 個消費(fèi)者實(shí)例各占一個隊(duì)列整體并行能力也上來了。差不多 40 分鐘以后80 萬積壓被徹底消化完系統(tǒng)恢復(fù)平穩(wěn)。這次復(fù)盤讓我拿到的教訓(xùn)很深刻擴(kuò)容前不看隊(duì)列數(shù)等于白花錢消費(fèi)邏輯里的非核心依賴在流量尖峰時要能一鍵摘除。4.2 日?？陕涞氐谋O(jiān)控告警和預(yù)防措施處理完了一次事故接下來要做的是不讓同樣的問題在下次發(fā)生。消息堆積的監(jiān)控體系我建議至少包含三個維度積壓量、消費(fèi)能力、異常率。RocketMQ 自身提供的 Dashboard 可以看消費(fèi)組的 diff 數(shù)據(jù)但更推薦把指標(biāo)接入 Prometheus搭配 rocketmq-exporter 采集 Broker 端的消息積壓、生產(chǎn)速率、消費(fèi)速率等指標(biāo)。rocketmq-exporter 的安裝其實(shí)不復(fù)雜準(zhǔn)備好 nameserver 地址和 exporter 的配置文件部署成一個單獨(dú)服務(wù)然后在 Prometheus 里添加抓取任務(wù)即可。這個過程官網(wǎng)文檔挺清楚照著做基本沒坑唯一要注意的是 exporter 版本和 RocketMQ 服務(wù)端版本最好保持一個大版本內(nèi)一致否則偶爾會出現(xiàn)指標(biāo)抓取不到的兼容問題。監(jiān)控面板搭好之后告警規(guī)則要定得有層次。最核心的幾條我通常這樣配消費(fèi)組積壓量超過 5000 條且持續(xù) 5 分鐘告警一次消費(fèi)組消費(fèi) TPS 掉到 0 時秒級告警消費(fèi)失敗率或重試次數(shù)在短時間內(nèi)翻倍時告警。積壓量這種指標(biāo)不要設(shè)置太低的閾值否則系統(tǒng)一抖動就告警告警轟炸反而讓人麻木消費(fèi) TPS 為 0 這種指標(biāo)則必須配置秒級或分鐘級告警因?yàn)檫@意味著消費(fèi)鏈路完全癱瘓。除了監(jiān)控告警日常也要做定期的存量巡檢。我建議每周挑一個業(yè)務(wù)低峰時段自動跑一遍主題消費(fèi)組位點(diǎn)巡檢腳本把積壓量超過閾值的消費(fèi)組列表拉出來給研發(fā)同學(xué)確認(rèn)原因。這么做的好處是很多小問題在變成事故前就被發(fā)現(xiàn)了比如某個消費(fèi)組由于代碼發(fā)布失敗一直沒啟動如果沒有巡檢它可能會在你大促前幾天才被注意到那種被動局面大家都不想經(jīng)歷。4.3 消息堆積問題速查表最后整理一個速查表大家可以把這張表貼在團(tuán)隊(duì)文檔里線上出問題時照著對一遍能省不少排查時間?，F(xiàn)象常見原因快速處理建議整體積壓持續(xù)上漲消費(fèi)TPS正常生產(chǎn)流量峰值超過消費(fèi)能力擴(kuò)容消費(fèi)者或增加隊(duì)列做好流量預(yù)估整體積壓上漲消費(fèi)TPS接近為0消費(fèi)端故障、線程池阻塞或?qū)嵗礄C(jī)抓線程棧、查日志先恢復(fù)消費(fèi)能力積壓集中在單個或少量隊(duì)列消息分配不均、對應(yīng)實(shí)例異常查看隊(duì)列分配情況檢查實(shí)例健康度積壓數(shù)字一直波動但實(shí)際消費(fèi)正常監(jiān)控統(tǒng)計(jì)延遲或消費(fèi)組名配置錯誤用命令行查看真實(shí)位點(diǎn)校準(zhǔn)監(jiān)控配置消費(fèi)失敗率高重試隊(duì)列積壓上升下游依賴異常、業(yè)務(wù)邏輯拋錯檢查異常堆棧隔離或降級失敗邏輯擴(kuò)容消費(fèi)者實(shí)例后積壓沒下降Topic隊(duì)列數(shù)不足或rebalance未觸發(fā)增加隊(duì)列數(shù)確認(rèn)實(shí)例都分配到了隊(duì)列死信隊(duì)列消息越積越多重試次數(shù)耗盡仍未成功查死信消息內(nèi)容寫補(bǔ)償程序人工處理這張表不可能覆蓋所有場景但覆蓋了我在實(shí)際運(yùn)維中遇到的大多數(shù)問題。大家在做技術(shù)方案、寫復(fù)盤文檔時也可以把類似表格放進(jìn)去讓新人接到告警時知道從哪里入手。最后再分享一個經(jīng)驗(yàn)。消息堆積處理得多了之后你會發(fā)現(xiàn)真正需要你直接用“重置位點(diǎn)跳過消息”來救場的場景很少絕大多數(shù)情況下是消費(fèi)邏輯本身有退化點(diǎn)或者容量預(yù)估遠(yuǎn)遠(yuǎn)不足。所以與其練一手騷操作不如老老實(shí)實(shí)把消費(fèi)鏈路做可靠把監(jiān)控做靈敏把預(yù)案做細(xì)。RocketMQ 消息堆積這道面試題能回答到“從原理分析到應(yīng)急處理、再到預(yù)防體系”這個顆粒度面試官看到的就不只是你會用工具而是你在真實(shí)系統(tǒng)里扛得住事。