水平擴容增加 consumer 的例項數量：
先修復 consumer 的問題，確保其恢復消費速度，然後將現有 consumer 都停掉；
新建乙個 topic，partition 是原來的 10 倍，臨時建立好原先 10 倍的 queue 數量；
然後寫乙個臨時分發資料的 consumer 程式，這個程式部署上去消費積壓的資料，消費
之後不做耗時的處理，直接均勻輪詢寫入臨時建立好的 10 倍數量的 queue；
接著臨時徵用 10 倍的機器來部署 consumer，每一批 consumer 消費乙個臨時 queue 的
資料。這種做法相當於是臨時將 queue 資源和 consumer 資源擴大 10 倍，以正常的 10 倍
速度來消費資料；
等快速消費完積壓資料之後，恢復原先部署的架構，重新用原先的 consumer 機器來消
費訊息。
首先這個mq得支援可伸縮性，使它在需要的時候可以快速擴容，所以得設計個分布式系統，這裡可以參考kafka的設計理念，就是broker，topic，partition，每個partition放乙個機器，只存一部分資料，如果資源不夠了，就給topic增加partition，然後做資料遷移，增加機器，於是就可以存放更多的資料了。
要考慮mq的資料落地磁碟，來避免程序掛了的時候資料丟失。磁碟順序讀寫的效率很高，所以可以採用順序寫的方式將資料落地磁碟。
要考慮mq的可用性。比如參考kafka的理念，設定 partition 和 replica 機制，還有考慮訊息的冪等性、可靠性、順序性。 參考
處理訊息佇列積壓
當消費者出現異常，很容易引起佇列積壓，如果一秒鐘1000個訊息，那麼乙個小時就是幾千萬的訊息積壓，是非常可怕的事情，但是生產線上又有可能會出現 當訊息積壓來不及處理，rabbitmq如果設定了訊息過期時間，那麼就有可能由於積壓無法及時處理而過期，這訊息就被丟失了 解決方法 不建議在生產環境使用資料過...
訊息積壓過多了怎麼辦
訊息積壓在mq中是一件很正常的事，但是積壓過多了，就可以會導致訊息的丟失，甚至系統的崩潰。那我們從事前的預防和事後的處理兩個方面去解決。我們如何預防訊息積壓呢，一般就是批量和增加併發這兩個方法，傳送端和消費端都可以從這兩個方面去處理。1.1 傳送端 1.批量。比如一次從資料庫中批量查出資料傳送mq。...
訊息佇列如何解決訊息積壓問題
訊息佇列訊息積壓了怎麼辦？q 剛開始是對這個疑問抱有質疑態度的，因為使用訊息佇列的其中目的就是削峰填谷，來避免高流量時，對下游服務的衝擊，所以使用訊息佇列進行緩衝，下游根據自己的消費能力去消費，我感覺這就是訊息積壓本就是使用訊息佇列的功能，怎麼會是問題呢？a 首先訊息積壓是正常現象，但凡是過多就不正...