消息積壓---通常處理方法

如何解決消息隊列的延時以及過時失效問題？消息隊列滿了之後該怎麼處理？

思考

1. 是什麼致使了消息積壓？是consumer程序bug？是consumer消費的速度落後於消息生產的速度？
2. 積壓了多長時間，積壓了多少許？
3. 對業務的影響？

解決思路

1. 若是僅僅是consumer消費的速度落後於消息生產的速度的話，能夠考慮採用擴容消費者羣組的方式。

2. 若是積壓比較嚴重，積壓了上百萬、上千萬的消息。

1. 修復現有consumer的問題，並將其停掉。
2. 從新建立一個容量更大的topic，好比patition是原來的10倍。
3. 編寫一個臨時consumer程序，消費原來積壓的隊列。該consumer不作任何耗時的操做，將消息均勻寫入新建立的隊列裏。
4. 將修復好的consumer部署到原來10倍的機器上消費新隊列。
5. 消息積壓解決後，恢復原有架構。

3. 若是消息已經丟失

因爲有的消息隊列有過時失效的機制，形成了大量的消息丟失。
這種狀況只能將丟失的那批數據，寫個臨時程序，一點一點的查出來，而後從新灌入mq裏面去。 

 

 

大量消息在mq裏積壓了幾個小時了還沒解決  

　　幾千萬條數據在MQ裏積壓了七八個小時，最簡單的方法可讓他恢復消費速度，而後等待幾個小時消費完畢。 

　　一個消費者一秒是1000條，一秒3個消費者是3000條，一分鐘是18萬條，1000多萬條 ，因此若是你積壓了幾百萬到上千萬的數據，即便消費者恢復了，也須要大概1小時的時間才能恢復過來  

　　通常這個時候，只能操做臨時緊急擴容了，具體操做步驟和思路以下：  

　　　　先修復consumer的問題，確保其恢復消費速度，而後將現有cnosumer都停掉

　　　　新建一個topic，partition是原來的10倍，臨時創建好原先10倍或者20倍的queue數量

　　　　而後寫一個臨時的分發數據的consumer程序，這個程序部署上去消費積壓的數據，消費以後不作耗時的處理，直接均勻輪詢寫入臨時創建好的10倍數量的queue

　　　　接着臨時徵用10倍的機器來部署consumer，每一批consumer消費一個臨時queue的數據

　　　　這種作法至關因而臨時將queue資源和consumer資源擴大10倍，以正常的10倍速度來消費數據

　　　　等快速消費完積壓數據以後，得恢復原先部署架構，從新用原先的consumer機器來消費消息

topic ---- kafka

數據庫 ---- ES

 

 

參考：

https://www.jianshu.com/p/ee7b1a2a2e61

http://www.javashuo.com/article/p-gifrdcxu-ge.html

 

消息積壓完整面試問題：

https://blog.csdn.net/weixin_44175121/article/details/90485143