一、面試題
如何解決消息隊列的延時以及過期失效問題？消息隊列滿了以后該怎么處理？有幾百萬消息持續積壓幾小時，說說怎么解決？
二、面試官心里分析
你看這問法，其實本質針對的場景，都是說，可能你的消費端出了問題，不消費了，或者消費的極其極其慢。接着就坑爹了，可能你的消息隊列集群的磁盤都快寫滿了，都沒人消費，這個時候怎么辦？或者是整個這就積壓了幾個小時，你這個時候怎么辦？或者是你積壓的時間太長了，導致比如rabbitmq設置了消息過期時間后就沒了怎么辦？
所以就這事兒，其實線上挺常見的，一般不出，一出就是大case，一般常見於，舉個例子，消費端每次消費之后要寫mysql，結果mysql掛了，消費端hang那兒了，不動了。或者是消費端出了個什么叉子，導致消費速度極其慢。
三、面試題分析
關於這個事兒，我們一個一個來梳理吧，先假設一個場景，我們現在消費端出故障了，然后大量消息在mq里積壓，現在事故了，慌了
1、大量消息在mq里積壓了幾個小時了還沒解決
幾千萬條數據在MQ里積壓了七八個小時，從下午4點多，積壓到了晚上很晚，10點多，11點多。
這個是我們真實遇到過的一個場景，確實是線上故障了，這個時候要不然就是修復consumer的問題，讓他恢復消費速度，然后傻傻的等待幾個小時消費完畢。這個肯定不能在面試的時候說吧。
一個消費者一秒是1000條，一秒3個消費者是3000條，一分鍾是18萬條，1000多萬條。
所以如果你積壓了幾百萬到上千萬的數據，即使消費者恢復了，也需要大概1小時的時間才能恢復過來。
一般這個時候，只能操作臨時緊急擴容了，具體操作步驟和思路如下：
（1）先修復consumer的問題，確保其恢復消費速度，然后將現有cnosumer都停掉；
（2）新建一個topic，partition是原來的10倍，臨時建立好原先10倍或者20倍的queue數量；
（3）然后寫一個臨時的分發數據的consumer程序，這個程序部署上去消費積壓的數據，消費之后不做耗時的處理，直接均勻輪詢寫入臨時建立好的10倍數量的queue；
（4）接着臨時征用10倍的機器來部署consumer，每一批consumer消費一個臨時queue的數據；
（5）這種做法相當於是臨時將queue資源和consumer資源擴大10倍，以正常的10倍速度來消費數據；
（6）等快速消費完積壓數據之后，得恢復原先部署架構，重新用原先的consumer機器來消費消息；
2、這里我們假設再來第二個坑
假設你用的是rabbitmq，rabbitmq是可以設置過期時間的，就是TTL，如果消息在queue中積壓超過一定的時間就會被rabbitmq給清理掉，這個數據就沒了。那這就是第二個坑了。這就不是說數據會大量積壓在mq里，而是大量的數據會直接搞丟。
這個情況下，就不是說要增加consumer消費積壓的消息，因為實際上沒啥積壓，而是丟了大量的消息。我們可以采取一個方案，就是批量重導，這個我們之前線上也有類似的場景干過。就是大量積壓的時候，我們當時就直接丟棄數據了，然后等過了高峰期以后，比如大家一起喝咖啡熬夜到晚上12點以后，用戶都睡覺了。
這個時候我們就開始寫程序，將丟失的那批數據，寫個臨時程序，一點一點的查出來，然后重新灌入mq里面去，把白天丟的數據給他補回來。也只能是這樣了。
假設1萬個訂單積壓在mq里面，沒有處理，其中1000個訂單都丟了，你只能手動寫程序把那1000個訂單給查出來，手動發到mq里去再補一次。
3、然后我們再來假設第三個坑
如果走的方式是消息積壓在mq里，那么如果你很長時間都沒處理掉，此時導致mq都快寫滿了，咋辦？這個還有別的辦法嗎？沒有，誰讓你第一個方案執行的太慢了，你臨時寫程序，接入數據來消費，消費一個丟棄一個，都不要了，快速消費掉所有的消息。然后走第二個方案，到了晚上再補數據吧。
另外，大家有什么好的想法，歡迎留言補充哦！
熱門內容：
1、為什么阿里巴巴不建議在for循環中使用"+"進行字符串拼接?
8、困擾多年的Java泛型解惑之 extends T>和 super T>
