如果你在你簡歷上寫上了熟悉RabbitMQ，那么你在面試時很有可能會被問到，如何解決MQ消息積壓？

要想將此問題回答完美，一定要多方面考慮。首先，我們要搞清楚是什么原因導致的消息積壓。我列舉了以下三種：

1）流量變大，而RabbitMQ服務器配置偏低，導致消息產生速度大于消費速度；

2）消費者故障，從而消息只增不減；

3）程序邏輯設計有問題，導致生產者持續生產消息，而消費者不消費或者消費慢；

當然，還有其它原因，上面三個已經能覆蓋80%以上的問題。下面就以這三種情況分別來說說如何應對。

對于第一種情況，很明顯就是資源不夠了，解決方法也很簡單，擴容即可。可以縱向擴容，即增加服務器資源，該加內存加內存，該加CPU加CPU。

如果縱向擴容不方便，那就橫向擴容，即將單機改為集群模式，增加集群節點，并且增加消費者數量，讓消費速度快起來！例如，原來是5個消費者，現在變成50個消費者！

對于第二種情況，要通過查看日志搞清楚為什么消費者會故障，據我多年經驗，發生此類問題大概率是程序代碼寫的不夠完美，跑著跑著導致內存溢出，然后消費者進程被殺。要想永久解決此問題，需要結合日志分析程序代碼，優化代碼。臨時解決方法是寫監控腳本，如果發現消費者進程中斷，需要重啟服務！

再來說第三個，這種情況發生的概率其實并不高，總之就是程序邏輯問題，判斷的方法也很簡單，持續觀察服務器的資源耗費情況，如果內存、CPU一切都正常，但就是隊列持續增長，而消費速度非常慢。此時，就需要好好查查程序代碼了。當然，可以嘗試增加消費者數量，看看是否有好轉。

上面說的只是“亡羊補牢”的操作，但還沒有說如何將當前已經積壓的隊列給快速消耗掉。

相信，當我們發現消息積壓時，想必問題已經比較嚴重了，或者說已經影響到業務正常運轉了，那么當務之急肯定是需要先將業務恢復正常。對于上面第二種情況，直接重啟相關服務，讓消費者恢復正常，定是首當其沖。

除此之外，還有一種“斷尾求生”的騷操作，就是新開一個隊列，將新產生的消息到新隊列里，消費者也到新隊列里消費。而老的隊列，則需要做一個異步處理，慢慢消費掉即可。

當然，如果積壓的消息不怎么重要，可有可無的話，那干脆直接刪除掉，這樣大家都省事不是。

審核編輯：劉清