在日常工作中使用rabbitmq偶爾會遇不可預料的情況導致的訊息積壓，一般出現訊息積壓基本上分為幾種情況：
消費者消費訊息的速度趕不上生產速度，這總問題主要是業務邏輯沒設計好消費者和生產者之間的平衡，需要改業務流程或邏輯已保證消費度跟上生產訊息的速，譬如增加消費者的數量等。
消費者出現異常，導致一直無法接收新的訊息，這種問題需要排查消費的邏輯是不是又問題，需要優化程式。
除了上面的者兩種問題，還有一些其他情況會導致訊息積壓，譬如一些系統是無法預計成產訊息的速度和頻率，又或者消費者的速度已經被限制，不能通過加新的消費者來解決，譬如不同的系統間的api對接，對接那一方就做了請求頻率的限制，或者對方系統承受不了太大的併發，還有一些系統如果是面對企業客戶，譬如電商，物流，倉儲等類似平台系統的客戶的下單是沒有規律的或者集中某乙個時間段下單的，這種就不能簡單的通過加消費者來解決，就需要分析具體業務來避免訊息積壓。
針對這種情況，我想到了4中解決思路：
拆分mq,生產者乙個mq，消費者乙個mq，寫乙個程式監聽生產者的mq模擬消費速度（譬如執行緒休眠），然後傳送到消費者的mq，如果訊息積壓則只需要處理生產者的mq的積壓訊息，不影響消費者mq
拆分mq,生產者乙個mq，消費者乙個mq，寫乙個程式監聽生產者的mq，定義乙個全域性靜態變數記錄上一次消費的時間，如果上一次時間和當前時間只差小於消費者的處理時間，則傳送到乙個延遲佇列（可以使用死信佇列實現）傳送到消費者的mq，如果訊息積壓則只需要處理生產者的mq的積壓訊息，不影響消費者mq
使用redis的list或zset做接收訊息快取，寫乙個程式按照消費者處理時間定時從redis取訊息傳送到mq
設定訊息過期時間，過期後轉入死信佇列，寫乙個程式處理死信訊息（重新如佇列或者即使處理或記錄到資料庫延後處理）
其中使用延時佇列會相對來說邏輯簡單，業務邏輯變更也不大，在rabbitmq中，可使用死信來及延時佇列外掛程式rabbitmq_delayed_message_exchange兩種方式實現延時佇列。
使用外掛程式可以在官網找到：
/// /// 傳送延時佇列訊息
///
///
///
/// 預設20
public void senddelayqueues(string message, string queuename,double delaymilliseconds,string bedeadletterprefix="bedeadletter_")
/// /// 設定延遲佇列接收的事件
///
///
///
/// 預設1
///
///
public void setdelayqueuesreceivedaction(actionaction, string queuename, ushort prefetchcount = 1,
bool autoack = false, int consumercount = 1)
var exchangename = queuename;
var routingkey = queuename;
for (int i = 0; i < consumercount; i++)
;//autoack自動訊息應答設定為false
channel.basicconsume(queue: queuename, autoack: autoack, consumer: consumer);}}
訊息積壓的處理
一 訊息積壓的原因 訊息積壓的直接原因，一定是系統中某個部分出現了效能問題，來不及處理上游傳送的訊息，才會導致訊息積壓。二 優化效能來避免訊息積壓 在使用訊息佇列的系統中，對於效能的優化，主要體現在生產者和消費者兩部分的業務邏輯中。對於訊息佇列本身的效能，作為使用者不需要太關注。主要原因是對於絕大多...
ActiveMQ處理積壓的訊息
如果消費者變為慢速消費者，那麼後面可能會導致訊息積壓，導致生產者速度也變慢，甚至停止。我們可以配置訊息的過期時間，並設定訊息過期丟棄策略，以及使用死信佇列來處理訊息的積壓。activemq提供了乙個timestampingbrokerplugin外掛程式，通過此外掛程式，我們可以為持久化訊息設定過期...
快速處理積壓訊息
場景二場景三 1 大量訊息在mq裡積壓了七八個小時還沒解決 一般的解決方案是修復消費者，讓消費者恢復消費速度。但是資料量大的情況下需要耗時很久。一般這個時候，只能操作緊急擴容了，1 先修復consumer的問題，確保其恢復消費的速度 2 新建乙個topic,partition是原來的10倍，臨時建立...