消息隊列產生嚴重消息堆積怎麼處理？

1. 爲何產生消息堆積？

大可能是由於 Consumer 出問題了，沒有及時發現，或者故障恢復須要較長的時間，致使大量消息積壓在 MQ 中。

2. 消息堆積會有什麼後果呢？

2.1 消息被丟棄

例如 RabbitMQ 有一個消息過時時間 TTL，過時的消息會被扔掉，這樣消息就完全沒有了。

2.2 磁盤滿了

若是堆積量太大，可能致使磁盤空間不足，那麼新消息就進不來了。

2.3 海量消息待處理

若是消息沒過時，而且磁盤空間也夠用，那麼就是產生海量消息等待被消費，Consumer 的噩夢。

3. 如何應對呢？

3.1 消息被丟棄的狀況

首先，要實現防止消息過時問題，不該該設置過時時間。

若是就是設置了過時時間，致使了消息丟失，怎麼補救呢？

那就只能在夜深人靜，趁着訪問量最低的時候，寫一個臨時程序來補消息了。

例若有訂單消息丟了，那就須要找出哪些訂單消息丟了，而後從新發到隊列。

3.2 磁盤不足的狀況

系統一般都是有監控的，達到空間閾值時就會發警報，這時就要立刻處理了。

例如，在其餘機器上建立臨時的消息隊列，再寫一個臨時的 Consumer，做爲消息的中轉，把消息積壓隊列中的消息取出來，放到臨時隊列裏面去。

快速疏散積壓的消息，讓磁盤空間恢復正常水平。

3.3 快速處理海量積壓消息

Consumer 恢復正常以後，面對堆積如山的消息，怎麼處理呢？

如何按照以前正常狀況處理的話，猴年馬月才能消費完，此過程當中還有新消息在不斷進來。

例如，積壓了 100 萬條，有 3 個 Consumer，每個每秒能處理 200 條，3 個 Consumer 每秒一共能處理 600 條。

大概須要一個多小時才能處理完。

這一個多小時又會積壓多少新的消息呢？

因此正常處理確定不行，須要提速。

例如 Kafka，這個消息積壓的 Topic 有 3 個 Partition，那最多就能用 3 個 Consumer，因此增長 Consumer 沒有用。

仍是可使用臨時隊列的方式。

新建一個 Topic，設置爲 20 個 Partition

Consumer 再也不處理業務邏輯了，只負責搬運，把消息放到臨時 Topic 中

這 20 個 Partition 能夠有 20個 Consumer 了，它們來處理原來的業務邏輯。

這 20 個 Consumer 每秒一共能處理 4000 條了，這樣幾分鐘就能夠處理完積壓的 100 萬條。

這幾分鐘新來的消息也不會太多，因此很快就能夠恢復正常水平，以後，再把總體結構恢復爲原來的形式。

小結一下，消息積壓仍是比較麻煩的，最好是提早防範，作好硬件和消息系統的健康監控。若是出現消息丟失，就要人工查找丟失的消息，而後補上。在消費不過來的時候，能夠考慮使用臨時隊列做爲中轉，提高處理能力。

推薦閱讀

OAuth2 圖解

輕鬆理解 Kubernetes 的核心概念

開發者必需要了解的架構技術趨勢：Service Mesh