一、訊息積壓的原因
訊息積壓的直接原因，一定是系統中某個部分出現了效能問題，來不及處理上游傳送的訊息，才會導致訊息積壓。
二、優化效能來避免訊息積壓
在使用訊息佇列的系統中，對於效能的優化，主要體現在生產者和消費者兩部分的業務邏輯中。對於訊息佇列本身的效能，作為使用者不需要太關注。主要原因是對於絕大多數使用訊息佇列的業務來說，訊息佇列本身的處理能力要遠大於業務系統的處理能力。所以對於訊息佇列的效能優化，更關注的是在訊息的收發兩端，我們的業務**怎麼和訊息佇列配合，達到乙個最佳效能。
1、傳送端效能優化
傳送端業務**的處理效能，實際上和訊息佇列的關係不大，因為一般傳送端都是先執行自己的業務邏輯，最後再傳送訊息。如果說，你的**傳送訊息的效能上不去，你需要優先檢查一下，是不是發訊息之前的業務邏輯耗時太多導致的。
對於傳送訊息的業務邏輯，只需要注意設定合適的併發和批量大小，就可以達到很好的傳送效能。
producer 傳送訊息的過程，producer 發訊息給 broker，broker 收到訊息後返回確認響應，這是一次完整的互動。假設這一次互動的平均時延是 1ms，我們把這 1ms 的時間分解開，它包括了下面這些步驟的耗時：
如果是單執行緒傳送，每次只傳送 1 條訊息，那麼每秒只能傳送 1000ms / 1ms * 1 條 /ms = 1000 條 訊息，這種情況下並不能發揮出訊息佇列的全部實力。無論是增加每次傳送訊息的批量大小，還是增加併發，都能成倍地提公升傳送效能。
至於到底是選擇批量傳送還是增加併發，主要取決於傳送端程式的業務性質。簡單來說，只要能夠滿足你的效能要求，怎麼實現方便就怎麼實現。
。很自然的，微服務在處理每次請求的時候，就在當前執行緒直接傳送訊息就可以了，因為所有 rpc 框架都是多執行緒支援多併發的，自然也就實現了並行傳送訊息
如果你的系統是乙個離線分析系統，離線系統在效能上的需求是它不關心時延，更注重整個系統的吞吐量。傳送端的資料都是來自於資料庫，這種情況就更適合批量傳送，你可以批量從資料庫讀取資料，然後批量來傳送訊息，同樣用少量的併發就可以獲得非常高的吞吐量。
2、消費端效能優化
使用訊息佇列時，大部分的效能問題都出現在消費端，如果消費的速度跟不上傳送端生產訊息的速度，就會造成訊息積壓。要是消費速度一直比生產速度慢，時間長了，整個系統就會出現問題。要麼訊息佇列的儲存填滿無法提供服務，要麼訊息丟失。
所以在設計系統時，一定要保證消費端的消費效能要高於生產端的傳送效能，這樣系統才能健康的持續執行。
消費端的效能優化除了優化消費業務邏輯外，也可以通過水平擴充套件，增加消費端的併發數來提公升總體的消費效能。注意：在擴容consumer的例項數量的同時，必須同步擴容主題中的分割槽（也叫佇列）數量，確保consumer的例項數和分割槽數量是相等的。如果consumer的例項數量超過分割槽數量，這樣的擴容實際上是沒有效果的，原因是對於消費者，在每個分割槽上實際上只能支援單執行緒消費。
很多消費程式，他們是這樣來解決消費慢的問題的：
它收訊息處理的業務邏輯可能比較慢，也很難再優化了，為了避免訊息積壓，在收到訊息的 onmessage 方法中，不處理任何業務邏輯，把這個訊息放到乙個記憶體佇列裡面就返回了。然後它可以啟動很多的業務執行緒，這些業務執行緒裡面是真正處理訊息的業務邏輯，這些執行緒從記憶體佇列裡取訊息處理，這樣它就解決了單個 consumer 不能並行消費的問題。
但是，這是乙個非常常見的錯誤方法！ 為什麼錯誤？因為會丟訊息。如果收訊息的節點發生宕機，在記憶體佇列中還沒來及處理的這些訊息就會丟失。在onmessage方法結束後，如果沒有拋異常，就自動ack了。而這個時候，訊息只是在記憶體佇列中，並沒有被真正處理完。
三、訊息積壓的緊急處理
如果日常系統正常運轉的時候，沒有積壓或者只有少量積壓很快就消費掉了，但是某乙個時刻，突然就開始積壓訊息並且積壓持續**。這種情況下需要你在短時間內找到訊息積壓的原因，迅速解決問題才不至於影響業務。
排查訊息積壓原因的方法：能導致積壓突然增加，最粗粒度的原因，只有兩種：要麼是傳送變快了，要麼是消費變慢了。
快速處理積壓訊息
場景二場景三 1 大量訊息在mq裡積壓了七八個小時還沒解決 一般的解決方案是修復消費者，讓消費者恢復消費速度。但是資料量大的情況下需要耗時很久。一般這個時候，只能操作緊急擴容了，1 先修復consumer的問題，確保其恢復消費的速度 2 新建乙個topic,partition是原來的10倍，臨時建立...
處理訊息佇列積壓
當消費者出現異常，很容易引起佇列積壓，如果一秒鐘1000個訊息，那麼乙個小時就是幾千萬的訊息積壓，是非常可怕的事情，但是生產線上又有可能會出現 當訊息積壓來不及處理，rabbitmq如果設定了訊息過期時間，那麼就有可能由於積壓無法及時處理而過期，這訊息就被丟失了 解決方法 不建議在生產環境使用資料過...
ActiveMQ處理積壓的訊息
如果消費者變為慢速消費者，那麼後面可能會導致訊息積壓，導致生產者速度也變慢，甚至停止。我們可以配置訊息的過期時間，並設定訊息過期丟棄策略，以及使用死信佇列來處理訊息的積壓。activemq提供了乙個timestampingbrokerplugin外掛程式，通過此外掛程式，我們可以為持久化訊息設定過期...