場景: 幾千萬條數據在MQ裏積壓了七八個小時,從下午4點多,積壓到了晚上很晚,10點多,11點多。線上故障了,這個時候要否則就是修復consumer的問題,讓他恢復消費速度,而後傻傻的等待幾個小時消費完畢。這個確定不行。一個消費者一秒是1000條,一秒3個消費者是3000條,一分鐘是18萬條,1000多萬條。 因此若是你積壓了幾百萬到上千萬的數據,即便消費者恢復了,也須要大概1小時的時間才能恢復過來。
解決方案:
這種時候只能操做臨時擴容,以更快的速度去消費數據了。具體操做步驟和思路以下:
①先修復consumer的問題,確保其恢復消費速度,而後將現有consumer都停掉。架構
②臨時創建好原先10倍或者20倍的queue數量(新建一個topic,partition是原來的10倍)。post
③而後寫一個臨時分發消息的consumer程序,這個程序部署上去消費積壓的消息,消費以後不作耗時處理,直接均勻輪詢寫入臨時建好分10數量的queue裏面。設計
④緊接着徵用10倍的機器來部署consumer,每一批consumer消費一個臨時queue的消息。cdn
⑤這種作法至關於臨時將queue資源和consumer資源擴大10倍,以正常速度的10倍來消費消息。blog
⑥等快速消費完了以後,恢復原來的部署架構,從新用原來的consumer機器來消費消息。 rabbitmq
假設你用的是rabbitmq,rabbitmq是能夠設置過時時間的,就是TTL,若是消息在queue中積壓超過必定的時間就會被rabbitmq給清理掉,這個數據就沒了。那這就是第二個坑了。這就不是說數據會大量積壓在mq裏,而是大量的數據會直接搞丟。
解決方案:
這種狀況下,實際上沒有什麼消息擠壓,而是丟了大量的消息。因此第一種增長consumer確定不適用。 這種狀況能夠採起 「批量重導」 的方案來進行解決。 在流量低峯期(好比夜深人靜時),寫一個程序,手動去查詢丟失的那部分數據,而後將消息從新發送到mq裏面,把丟失的數據從新補回來。資源
若是走的方式是消息積壓在mq裏,那麼若是你很長時間都沒處理掉,此時致使mq都快寫滿了,咋辦?這個還有別的辦法嗎?
解決方案:
這個就沒有辦法了,確定是第一方案執行太慢,這種時候只好採用 「丟棄+批量重導」 的方式來解決了。部署
首先,臨時寫個程序,鏈接到mq裏面消費數據,收到消息以後直接將其丟棄,快速消費掉積壓的消息,下降MQ的壓力,而後走第二種方案,在晚上夜深人靜時去手動查詢重導丟失的這部分數據。get
上一篇《如何保證消息按順序執行》kafka
下一篇《若是讓你設計一個MQ,你怎麼設計》