在使用消息隊列遇到的問題中，消息積壓這個問題，應(yīng)該是最常遇到的問題了，消息積壓的直接原因，一定是系統(tǒng)中的某個部分出現(xiàn)了性能問題，來不及處理上游發(fā)送的消息，才會導(dǎo)致消息積壓。

在使用消息隊列時，如何來優(yōu)化代碼的性能，避免出現(xiàn)消息積壓。然后再來看看，如果你的線上系統(tǒng)出現(xiàn)了消息積壓，該如何進行緊急處理，最大程度地避免消息積壓對業(yè)務(wù)的影響。

消息解壓的本質(zhì)與根源分析

想要知道本質(zhì)原因，我們需要知道消息生命周期的瓶頸全景圖。

圖片

總結(jié)下出現(xiàn)消息積壓的場景有以下三種：

1. 生產(chǎn)端：突發(fā)流量紅方、網(wǎng)絡(luò)波動、序列化方式性能瓶頸
2. Broker 端：磁盤 I/O、分區(qū)數(shù)不足，副本同步延遲。
3. 消費端：消費線程不足、業(yè)務(wù)邏輯處理耗時阻塞、外部依賴超時。

圖片

“

Chaya：對于絕大多數(shù)使用消息隊列的業(yè)務(wù)來說，消息隊列本身的處理能力要遠大于業(yè)務(wù)系統(tǒng)的處理能力。

主流消息隊列的單個節(jié)點，消息收發(fā)的性能可以達到每秒鐘處理幾萬至幾十萬條消息的水平，還可以通過水平擴展 Broker 的實例數(shù)成倍地提升處理能力。

業(yè)務(wù)系統(tǒng)的業(yè)務(wù)邏輯遠比消息隊列要復(fù)雜，我們關(guān)注的核心是消費端業(yè)務(wù)邏輯的性能優(yōu)化來比避免消息積壓。

生產(chǎn)端性能優(yōu)化

發(fā)送端業(yè)務(wù)代碼的處理性能，實際上和消息隊列的關(guān)系不大，因為一般發(fā)送端都是先執(zhí)行自己的業(yè)務(wù)邏輯，最后再發(fā)送消息。

如果說，你的代碼發(fā)送消息的性能上不去，你需要優(yōu)先檢查一下，是不是發(fā)消息之前的業(yè)務(wù)邏輯耗時太多導(dǎo)致的。

如果發(fā)送端是一個微服務(wù)，主要接受 RPC 請求處理在線業(yè)務(wù)。很自然的，微服務(wù)在處理每次請求的時候，就在當(dāng)前線程直接發(fā)送消息就可以了，因為所有 RPC 框架都是多線程支持多并發(fā)的，自然也就實現(xiàn)了并行發(fā)送消息。

如果是一個離線分析系統(tǒng)，離線系統(tǒng)在性能上的需求是什么呢？它不關(guān)心時延，更注重整個系統(tǒng)的吞吐量。

發(fā)送端的數(shù)據(jù)都是來自于數(shù)據(jù)庫，這種情況就更適合批量發(fā)送，你可以批量從數(shù)據(jù)庫讀取數(shù)據(jù)，然后批量來發(fā)送消息，同樣用少量的并發(fā)就可以獲得非常高的吞吐量。

“

余姐姐：有沒有一個架構(gòu)方案，兩種場景都可以適應(yīng)的極致性能優(yōu)化方案？

姐姐真是貪心呀……

不管離線還是微服務(wù)處理業(yè)務(wù)業(yè)務(wù)邏輯發(fā)送消息，想要追求極致的發(fā)送性能，可以使用本地內(nèi)存隊列緩沖架構(gòu)優(yōu)化。

圖片

關(guān)鍵優(yōu)化策略

1. 批量發(fā)送：合并小消息減少網(wǎng)絡(luò) IO
2. 數(shù)據(jù)壓縮：使用 Snappy/LZ4 減少傳輸量
3. 異步確認(rèn)：非阻塞等待 Broker 響應(yīng)
4. 分區(qū)選擇：基于業(yè)務(wù)鍵保證分區(qū)均勻

Broker 端優(yōu)化

Broker 端的話，通常可以通過擴展分區(qū)、磁盤存儲優(yōu)化、合理調(diào)整 Broker 參數(shù)實現(xiàn)。

最怕的就是有的公司引入了一些開源 MQ，在開源基礎(chǔ)上包了一層皮封裝的公司。

因為隨著時間的發(fā)展，原先開源的那套可能已經(jīng)退出歷史舞臺，性能也很差，但是公司魔改過，很多業(yè)務(wù)系統(tǒng)都在使用，根本改不了。

磁盤優(yōu)化

圖片

Kafka 分區(qū)動態(tài)擴容

圖片

關(guān)鍵配置優(yōu)化（Kafka 3.x）

# Kafka黃金配置
# 網(wǎng)絡(luò)吞吐
num.network.threads=8 # 網(wǎng)絡(luò)線程數(shù)
queued.max.requests=1000 # 請求隊列大小

# 磁盤優(yōu)化
num.io.threads=16 # IO線程數(shù)
log.flush.interval.messages=10000
log.flush.interval.ms=1000

# 內(nèi)存管理
log.retention.bytes=-1 # 按容量保留
log.segment.bytes=1073741824 # 1GB段文件

消費端優(yōu)化

余姐姐：  好的愛情不是一味地索取，更不是毫無意義的付出，而是互相成長。

消息隊列也是愛情的折射。

使用消息隊列的時候，大部分的性能問題都出現(xiàn)在消費端，如果消費的速度跟不上發(fā)送端生產(chǎn)消息的速度，就會造成消息積壓。最后系統(tǒng)崩塌。

所以消息的發(fā)送與消息的消費需要同頻。要是消費速度一直比生產(chǎn)速度慢，時間長了，整個系統(tǒng)就會出現(xiàn)問題，要么，消息隊列的存儲被填滿無法提供服務(wù)，要么消息丟失，這對于整個系統(tǒng)來說都是嚴(yán)重故障。

我們在設(shè)計系統(tǒng)的時候，一定要保證消費端的消費性能要高于生產(chǎn)端的發(fā)送性能，這樣的系統(tǒng)才能健康的持續(xù)運行。

消費端的性能優(yōu)化除了優(yōu)化消費業(yè)務(wù)邏輯以外，也可以通過水平擴容，增加消費端的并發(fā)數(shù)來提升總體的消費性能。

特別需要注意的一點是，在擴容 Consumer 的實例數(shù)量的同時，必須同步擴容主題中的分區(qū)（也叫隊列）數(shù)量，確保 Consumer 的實例數(shù)和分區(qū)數(shù)量是相等的。

“

Chaya：如果愛到了盡頭，被壓的喘不過氣了該怎么辦？同樣的，處理消息的業(yè)務(wù)邏輯很難再優(yōu)化了，為了避免消息積壓，我能否先不處理消息，直接放到一個內(nèi)存隊列就返回 ack？然后再啟動一些線程從內(nèi)存隊列取消息處理。

有一種愛就做放手……當(dāng)愛已成往事，你能做的只有交給時間去處理。

如果不能提高處理該消息的業(yè)務(wù)邏輯，只是放到一個內(nèi)存隊列就返回 MQ ack，這是一種極其錯誤的實現(xiàn)方式。

為什么錯誤？因為會丟消息。如果收消息的節(jié)點發(fā)生宕機，在內(nèi)存隊列中還沒來及處理的這些消息就會丟失。

消息積壓了該如何處理？

還有一種消息積壓的情況是，日常系統(tǒng)正常運轉(zhuǎn)的時候，沒有積壓或者只有少量積壓很快就消費掉了，但是某一個時刻，突然就開始積壓消息并且積壓持續(xù)上漲。

這種情況下需要你在短時間內(nèi)找到消息積壓的原因，迅速解決問題才不至于影響業(yè)務(wù)。

“

Chaya：能導(dǎo)致消息積壓忽然增加，通常只有兩種情況：要么是發(fā)送變快了，要么是消費變慢了。

大部分消息隊列都內(nèi)置了監(jiān)控的功能，只要通過監(jiān)控數(shù)據(jù)，很容易確定是哪種原因。

如果是單位時間發(fā)送的消息增多，比如說是趕上大促或者搶購，短時間內(nèi)不太可能優(yōu)化消費端的代碼來提升消費性能，唯一的方法是通過擴容消費端的實例數(shù)來提升總體的消費能力。

還有一種不太常見的情況，你通過監(jiān)控發(fā)現(xiàn)，無論是發(fā)送消息的速度還是消費消息的速度和原來都沒什么變化，這時候你需要檢查一下你的消費端，是不是消費失敗導(dǎo)致的一條消息反復(fù)消費這種情況比較多，這種情況也會拖慢整個系統(tǒng)的消費速度。

總結(jié)

消息積壓治理的本質(zhì)是資源與需求的動態(tài)平衡藝術(shù)，需要建立三層防御體系：

1. 事前預(yù)防：通過容量規(guī)劃、代碼優(yōu)化和壓力測試構(gòu)建第一道防線

• 優(yōu)化生產(chǎn)發(fā)送模式
• 合理設(shè)置分區(qū)數(shù)量
• 設(shè)計彈性消費架構(gòu)

2. 事中監(jiān)控：建立全鏈路監(jiān)控和智能預(yù)警系統(tǒng)

• 實時跟蹤生產(chǎn)/消費速率比
• 設(shè)置多級積壓閾值告警
• 可視化關(guān)鍵性能指標(biāo)

3. 事后應(yīng)急：制定分級響應(yīng)預(yù)案

• 輕度積壓：動態(tài)擴容消費者
• 中度積壓：限流+降級非核心

真正的消息專家不是讓系統(tǒng)永不積壓，而是當(dāng)洪水來襲時，能在業(yè)務(wù)感知前完成疏導(dǎo)。

這要求我們在代碼優(yōu)化、架構(gòu)設(shè)計和應(yīng)急預(yù)案三方面建立縱深防御體系。