消息堆積
為什么會產生消息堆積？
大多數是因為Consumer 出問題了，沒有及時發現，或者故障恢復需要較長時間，導致大量消息積壓在消息隊列中。
消息隊列堆積會造成什么后果？
- 消息被丟棄
- 磁盤滿了
- 海量消息需要處理
解決方案：
- 增加消費者或后台相關組件的吞吐能力
- 增加消費的多線程處理
- 根據不同的業務實現不同的丟棄任務，選擇不同的策略淘汰任務
- 默認情況下，RabbitMQ消費者為單線程串行消費，設置並行消費兩個關鍵屬性，他們設置的是對每個消費者在初始化的時候設置的並發消費者個數，prefetchCount 是每次一次性從broker中獲取的待消費的消息個數。
- concurrentConsumer
- prefetchConcurrentConsumer
小結：
消息積壓還是比較麻煩的，最好是提交防范，做好硬件和消息系統的健康監控。如果出現消息丟失，就要人中查找丟失的消息，然后補上，如果出現消費不過來的情況，考慮使用臨時隊列作為中轉，提升處理能力。
消息丟失
解決方案：
- 持久化
- 消息確認機制
消息在生產者，消息隊列，消費者中都有可能丟失。
1. 在生產者中丟失
原因:生產者發送消息成功后，消息隊列沒有收到消息，消息在從生產者傳輸到隊列的過程中丟失，一般可能是網絡不穩定。
解決方案： 發送方采用消息確認機制，當消息成功被MQ接收到后， 會給生產者發一個確認消息，表示成功接收。
2. 在消息隊列中丟失
原因：消息到MQ后， 還沒有被消費就被MQ給丟失了。比如MQ服務器宕機或者未進行持久化重啟。
解決方案：持久化交換機，隊列和消息。確保MQ服務器重啟時仍然能從磁盤恢復對應的隊列，交換機和消息，然后我們把MQ 做多台分布式集群，防止出現所有的MQ服務器掛掉。
注意： 交換機，隊列和消息都要持久化。
3. 在消費者中丟失
原因：默認消費者消費的時，設置的是自動回復MQ, 收到了消息，MQ會立刻刪除自身保存的這條消息，如果消息已經在MQ中被刪除，但消費者的業務處理出現異常或者宕機，那么就導致改消息沒有被成功處理從而導致消息丟失。
解決方案： 設置手動ACK。