MQ的作用
1）解耦：在項目啟動之初是很難預測未來會遇到什么困難的，消息中間件在處理過程中插入了一個隱含的，基於數據的接口層，兩邊都實現這個接口，這樣就允許獨立的修改或者擴展兩邊的處理過程，只要兩邊遵守相同的接口約束即可。
2）冗余（存儲）：在某些情況下處理數據的過程中會失敗，消息中間件允許把數據持久化知道他們完全被處理
擴展性：消息中間件解耦了應用的過程，所以提供消息入隊和處理的效率是很容易的，只需要增加處理流程就可以了。
3）削峰：在訪問量劇增的情況下，但是應用仍然需要發揮作用，但是這樣的突發流量並不常見。而使用消息中間件采用隊列的形式可以減少突發訪問壓力，不會因為突發的超時負荷要求而崩潰
4）可恢復性：當系統一部分組件失效時，不會影響到整個系統。消息中間件降低了進程間的耦合性，當一個處理消息的進程掛掉后，加入消息中間件的消息仍然可以在系統恢復后重新處理
5）順序保證：在大多數場景下，處理數據的順序也很重要，大部分消息中間件支持一定的順序性
6）緩沖：消息中間件通過一個緩沖層來幫助任務最高效率的執行
7）異步通信：通過把把消息發送給消息中間件，消息中間件並不立即處。
本文只討論削峰填谷的應用場景：
舉個業務場景的栗子，秒殺業務：
上游發起下單操作
下游完成秒殺業務邏輯（庫存檢查，庫存凍結，余額檢查，余額凍結，訂單生成，余額扣減，庫存扣減，生成流水，余額解凍，庫存解凍）
上游下單業務簡單，每秒發起了10000個請求，下游秒殺業務復雜，每秒只能處理2000個請求，很有可能上游不限速的下單，導致下游系統被壓垮，引發雪崩。
為了避免雪崩，常見的優化方案有兩種：
1）業務上游隊列緩沖，限速發送
2）業務下游隊列緩沖，限速執行
不管哪種方案，都會引入業務的復雜性，有“緩沖流量”需求的系統都需要加入類似的機制（具體怎么保證消息可達，見《消息總線能否實現消息必達？》），正所謂“通用痛點統一解決”，需要一個通用的機制解決這個問題。
問：如何緩沖流量？
答：明明中間有了MQ，並且MQ有消息落地的機制，為何不能利用MQ來做緩沖呢？顯然是可以的。
問：MQ怎么改能緩沖流量？
答：由MQ-server推模式，升級為MQ-client拉模式。
MQ-client根據自己的處理能力，每隔一定時間，或者每次拉取若干條消息，實施流控，達到保護自身的效果。並且這是MQ提供的通用功能，無需上下游修改代碼。
問：如果上游發送流量過大，MQ提供拉模式確實可以起到下游自我保護的作用，會不會導致消息在MQ中堆積？
答：下游MQ-client拉取消息，消息接收方能夠批量獲取消息，需要下游消息接收方進行優化，方能夠提升整體吞吐量，例如：批量寫。
結論
1）MQ-client提供拉模式，定時或者批量拉取，可以起到削平流量，下游自我保護的作用（MQ需要做的）
2）要想提升整體吞吐量，需要下游優化，例如批量處理等方式（消息接收方需要做的）
原文：https://blog.csdn.net/u011676417/article/details/70168194
原文：https://www.jianshu.com/p/adf0b7de6753