幾千萬條數據在 MQ 裏積壓了七八個小時,從下午 4 點多,積壓到了晚上 11 點多。這個是咱們真實遇到過的一個場景,確實是線上故障了,這個時候要否則就是修復 consumer 的問題,讓它恢復消費速度,而後傻傻的等待幾個小時消費完畢。這個確定不能在面試的時候說吧。java
一個消費者一秒是 1000 條,一秒 3 個消費者是 3000 條,一分鐘就是 18 萬條。因此若是你積壓了幾百萬到上千萬的數據,即便消費者恢復了,也須要大概 1 小時的時間才能恢復過來。git
通常這個時候,只能臨時緊急擴容了,具體操做步驟和思路以下:github
假設你用的是 RabbitMQ,RabbtiMQ 是能夠設置過時時間的,也就是 TTL。若是消息在 queue 中積壓超過必定的時間就會被 RabbitMQ 給清理掉,這個數據就沒了。那這就是第二個坑了。這就不是說數據會大量積壓在 mq 裏,而是大量的數據會直接搞丟。面試
這個狀況下,就不是說要增長 consumer 消費積壓的消息,由於實際上沒啥積壓,而是丟了大量的消息。咱們能夠採起一個方案,就是批量重導,這個咱們以前線上也有相似的場景幹過。就是大量積壓的時候,咱們當時就直接丟棄數據了,而後等過了高峯期之後,好比你們一塊兒喝咖啡熬夜到晚上12點之後,用戶都睡覺了。這個時候咱們就開始寫程序,將丟失的那批數據,寫個臨時程序,一點一點的查出來,而後從新灌入 mq 裏面去,把白天丟的數據給他補回來。也只能是這樣了。架構
假設 1 萬個訂單積壓在 mq 裏面,沒有處理,其中 1000 個訂單都丟了,你只能手動寫程序把那 1000 個訂單給查出來,手動發到 mq 裏去再補一次。spa
若是消息積壓在 mq 裏,你很長時間都沒有處理掉,此時致使 mq 都快寫滿了,咋辦?這個還有別的辦法嗎?沒有,誰讓你第一個方案執行的太慢了,你臨時寫程序,接入數據來消費,消費一個丟棄一個,都不要了,快速消費掉全部的消息。而後走第二個方案,到了晚上再補數據吧。資源