場景二場景三
（1）大量訊息在mq裡積壓了七八個小時還沒解決
一般的解決方案是修復消費者，讓消費者恢復消費速度。但是資料量大的情況下需要耗時很久。
一般這個時候，只能操作緊急擴容了，
1）先修復consumer的問題，確保其恢復消費的速度
2) 新建乙個topic,partition是原來的10倍，臨時建立好原先10倍或者20倍的queue數量
3）寫乙個臨時的分發資料的conumer程式，這個程式部署上去消費積壓的資料，消費之後不做耗時處理，直接均勻輪詢寫入臨時建立好的10倍數量的queue
4)臨時徵用10倍的機器來部署consumer,每一批consumer消費乙個臨時的queue的資料
5）這種做法相當於是將臨時queue資源和consumer資源擴大10倍，以正常的10倍的速度消費資料
6）等快速消費完積壓的資料之後，得恢復原先部署的架構，重新用原來的consumer機器來消費資料
假設你用的是rabbitmq，rabbitmq是可以設定過期時間的，就是ttl,如果訊息在queue中積壓超過一定的時間就會被rabbitmq給清理掉，這個資料就沒了，這就不會有大量的資料積壓在mq裡面，而是大量的資料直接丟失。
遇到這種情況的解決方案：批量重導。
積壓在mq裡面的訊息很久沒有處理掉，此時導致mq快寫滿了。這時候我們可以採用方案二 等高峰期過了再來補資料。
處理訊息佇列積壓
當消費者出現異常，很容易引起佇列積壓，如果一秒鐘1000個訊息，那麼乙個小時就是幾千萬的訊息積壓，是非常可怕的事情，但是生產線上又有可能會出現 當訊息積壓來不及處理，rabbitmq如果設定了訊息過期時間，那麼就有可能由於積壓無法及時處理而過期，這訊息就被丟失了 解決方法 不建議在生產環境使用資料過...
訊息積壓的處理
一 訊息積壓的原因 訊息積壓的直接原因，一定是系統中某個部分出現了效能問題，來不及處理上游傳送的訊息，才會導致訊息積壓。二 優化效能來避免訊息積壓 在使用訊息佇列的系統中，對於效能的優化，主要體現在生產者和消費者兩部分的業務邏輯中。對於訊息佇列本身的效能，作為使用者不需要太關注。主要原因是對於絕大多...
ActiveMQ處理積壓的訊息
如果消費者變為慢速消費者，那麼後面可能會導致訊息積壓，導致生產者速度也變慢，甚至停止。我們可以配置訊息的過期時間，並設定訊息過期丟棄策略，以及使用死信佇列來處理訊息的積壓。activemq提供了乙個timestampingbrokerplugin外掛程式，通過此外掛程式，我們可以為持久化訊息設定過期...