如何解決RabbitMQ消息積壓的問題？

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

要想將此問題回答完美，一定要多方面考慮。首先，我們要搞清楚是什么原因?qū)е碌南⒎e壓。我列舉了以下三種：

1）流量變大，而RabbitMQ服務(wù)器配置偏低，導(dǎo)致消息產(chǎn)生速度大于消費(fèi)速度；

2）消費(fèi)者故障，從而消息只增不減；

3）程序邏輯設(shè)計有問題，導(dǎo)致生產(chǎn)者持續(xù)生產(chǎn)消息，而消費(fèi)者不消費(fèi)或者消費(fèi)慢；

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

對于第一種情況，很明顯就是資源不夠了，解決方法也很簡單，擴(kuò)容即可?？梢钥v向擴(kuò)容，即增加服務(wù)器資源，該加內(nèi)存加內(nèi)存，該加CPU加CPU。

如果縱向擴(kuò)容不方便，那就橫向擴(kuò)容，即將單機(jī)改為集群模式，增加集群節(jié)點(diǎn)，并且增加消費(fèi)者數(shù)量，讓消費(fèi)速度快起來！例如，原來是5個消費(fèi)者，現(xiàn)在變成50個消費(fèi)者！

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

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

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

相信，當(dāng)我們發(fā)現(xiàn)消息積壓時，想必問題已經(jīng)比較嚴(yán)重了，或者說已經(jīng)影響到業(yè)務(wù)正常運(yùn)轉(zhuǎn)了，那么當(dāng)務(wù)之急肯定是需要先將業(yè)務(wù)恢復(fù)正常。對于上面第二種情況，直接重啟相關(guān)服務(wù)，讓消費(fèi)者恢復(fù)正常，定是首當(dāng)其沖。

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

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

審核編輯：劉清