**：訊息佇列訊息積壓了怎麼辦？
q:剛開始是對這個疑問抱有質疑態度的，因為使用訊息佇列的其中目的就是削峰填谷，來避免高流量時，對下游服務的衝擊，所以使用訊息佇列進行緩衝，下游根據自己的消費能力去消費，
我感覺這就是訊息積壓本就是使用訊息佇列的功能，怎麼會是問題呢？
a:首先訊息積壓是正常現象，但凡是過多就不正常了。積壓越來越多就需要處理了。就像乙個水庫，日常蓄水是正常的，但下游洩洪能力太差，導致水庫水位一直不停的**，這個就不正常了。
1、broker
其實不用太關注訊息佇列，因為訊息佇列本身的處理能力要遠遠大於業務系統的處理能力。主流訊息佇列的單個節點，訊息收發的效能可以達到每秒鐘處理幾萬至幾十萬條訊息的水平，還可以通過水平擴充套件 broker 的例項數成倍地提公升處理能力。
2、producer端效能優化
producer端對訊息積壓的影響不大，但是對producer端傳送訊息的效能有要求。一般是先執行自己的業務邏輯，最後再傳送訊息。如果說，你的**傳送訊息的效能上不去，你需要優先檢查一下，是不是發訊息之前的業務邏輯耗時太多導致的。
對於傳送訊息的業務邏輯來說，設定批量傳送及批量傳送的大小可以提高傳送端的傳送效能
producer 傳送訊息的過程，producer 發訊息給 broker，broker 收到訊息後返回確認響應，這是一次完整的互動。假設這一次互動的平均時延是 1ms，我們把這 1ms 的時間分解開，它包括了下面這些步驟的耗時：傳送端準備資料、序列化訊息、構造請求等邏輯的時間，也就是傳送端在傳送網路請求之前的耗時；傳送訊息和返回響應在網路傳輸中的耗時；broker 處理訊息的時延。如果是單執行緒傳送，每次只傳送 1 條訊息，那麼每秒只能傳送 1000ms / 1ms * 1 條 /ms = 1000 條 訊息，這種情況下並不能發揮出訊息佇列的全部實力。
無論是增加每次傳送訊息的批量大小，還是增加併發，都能成倍地提公升傳送效能。至於到底是選擇批量傳送還是增加併發，主要取決於傳送端程式的業務性質。
發生訊息積壓後，producer端服務降級，關閉一些非核心業務，減少訊息的產生。
3、consumer端效能優化
發生訊息積壓，主要原因就是消費端的消費能力跟不上生產端的生產速度。
等待積壓的訊息被消費，恢復到正常狀態，撤掉擴容伺服器。
沒有擴容前：
擴容後：
處理訊息佇列積壓
當消費者出現異常，很容易引起佇列積壓，如果一秒鐘1000個訊息，那麼乙個小時就是幾千萬的訊息積壓，是非常可怕的事情，但是生產線上又有可能會出現 當訊息積壓來不及處理，rabbitmq如果設定了訊息過期時間，那麼就有可能由於積壓無法及時處理而過期，這訊息就被丟失了 解決方法 不建議在生產環境使用資料過...
訊息積壓 訊息丟失解決方案
問題本質都在於你的消費端可能出了問題，不消費或消費的太慢！更可怕的是由於積壓時間太長，導致如果起初還設定了ttl後失效了怎麼辦？其實資料積壓的問題是架構設計不合理。丟失的資料是通過日誌找回來,如果日誌也找不到了 那就沒招了 一般這時，只能操作臨時緊急擴容了，具體操作步驟和思路如下 先修復consum...
如何解決訊息佇列的延時以及過期失效問題？
如果你積壓了幾百萬到上千萬的資料，即使消費者恢復了，也需要大概1小時的時間才能恢復過來 一般這個時候，只能操作臨時緊急擴容了，具體操作步驟和思路如下 1 先修復consumer的問題，確保其恢復消費速度，然後將現有cnosumer都停掉 2 新建乙個topic，partition是原來的10倍，臨時...