消息積壓是我們在使用消息隊列時經常遇到的問題，它的直接原因是系統中某個部分出現了性能問題，沒有來得及處理上游發送的消息。

優化性能避免消息積壓

當我們引入消息系統後，站在消息系統的角度，整個系統可以分為三部分：1. 消息生產者，2. 消息隊列，3. 消息消費者。

我們在談論優化性能避免積壓消息時，重點會放在消息生產者和消息消費者這兩部分。對於絕大多數使用消息隊列的業務來說，消息隊列本身的處理能力要遠大於業務系統的處理能力。

消息生產者性能優化

如果我們的代碼發送消息的性能有問題，我們可以檢查一下是不是發消息之前的業務邏輯耗時太多了。

我們可以通過調整發送消息的批量大小，或者增加併發，來解決消息生產者面臨的問題，至於應該選擇批量發送還是增加併發，主要取決於發送端程式的業務性質。

• 線上運行的微服務，主要接收RPC請求處理線上業務，它對請求響應時延比較敏感，適合併發的方式來提升性能。
• 離線分析系統，不關心時延，更註重整個系統的吞吐量，這種情況適用於批量方式來提升性能。

消息消費者性能優化

我們要保證消費端的性能要好於生產端的發送性能，這樣的系統才能健康的持續運行。

消費端除了優化消費業務之外，也可以通過水平擴容，增加消費端的併發數來提升性能，需要註意的是，在擴容消費者的實例數量的同時，必須同步擴容主題中的分區（隊列）數量，確保Consumer的數量和分區的數量是儘量相等的。

如果Consumer的實例數量超過分區數量，這樣的擴容是完全沒有效果的，因為同一個分區（隊列）同時只能有一個Consumer去處理消息。

怎麼處理積壓消息？

導致消息隊列突然增加積壓的原因有兩種：要麼消息發送變快了，要麼消息消費變慢了。

大部分消息隊列都內置了監控的功能，只要通過監控數據，很容易確定是哪種原因。

如果短時間內沒有足夠的伺服器資源區進行擴容，那麼可以考慮對服務進行系統降級，通過關閉一些不重要的業務，減少發送方發送的數據，最低限度讓系統保持正常運轉，服務一些重要業務。

如果我們發現無論是發送消息的速度還是消費消息的速度和原來相比沒有什麼變化，可以去檢查一下消費端，看看是不是因為消費失敗導致了一條消息被反覆消費，這樣也會拖慢這個系統去消費消息的速度。