問：為什么會有本文？
答：上一篇文章《到底什么時候該使用MQ？》引起了廣泛的討論，有朋友回復說，MQ的還有一個典型應用場景是緩沖流量，削峰填谷，本文將簡單介紹下，MQ要實現什么細節，才能緩沖流量，削峰填谷。
問：站點與服務，服務與服務上下游之間，一般如何通訊？
答：有兩種常見的方式
一種是“直接調用”，通過RPC框架，上游直接調用下游。
在某些業務場景之下（具體哪些業務場景，見《到底什么時候該使用MQ？》），可以采用“MQ推送”，上游將消息發給MQ，MQ將消息推送給下游。
問：為什么會有流量沖擊？
答：不管采用“直接調用”還是“MQ推送”，都有一個缺點，下游消息接收方無法控制到達自己的流量，如果調用方不限速，很有可能把下游壓垮。
舉個栗子，秒殺業務：
上游發起下單操作
下游完成秒殺業務邏輯（庫存檢查，庫存凍結，余額檢查，余額凍結，訂單生成，余額扣減，庫存扣減，生成流水，余額解凍，庫存解凍）
上游下單業務簡單，每秒發起了10000個請求，下游秒殺業務復雜，每秒只能處理2000個請求，很有可能上游不限速的下單，導致下游系統被壓垮，引發雪崩。
為了避免雪崩，常見的優化方案有兩種：
1）業務上游隊列緩沖，限速發送
2）業務下游隊列緩沖，限速執行
不管哪種方案，都會引入業務的復雜性，有“緩沖流量”需求的系統都需要加入類似的機制（具體怎么保證消息可達，見《消息總線能否實現消息必達？》），正所謂“通用痛點統一解決”，需要一個通用的機制解決這個問題。
問：如何緩沖流量？
答：明明中間有了MQ，並且MQ有消息落地的機制，為何不能利用MQ來做緩沖呢？顯然是可以的。
問：MQ怎么改能緩沖流量？
答：由MQ-server推模式，升級為MQ-client拉模式。
MQ-client根據自己的處理能力，每隔一定時間，或者每次拉取若干條消息，實施流控，達到保護自身的效果。並且這是MQ提供的通用功能，無需上下游修改代碼。
問：如果上游發送流量過大，MQ提供拉模式確實可以起到下游自我保護的作用，會不會導致消息在MQ中堆積？
答：下游MQ-client拉取消息，消息接收方能夠批量獲取消息，需要下游消息接收方進行優化，方能夠提升整體吞吐量，例如：批量寫。
結論
1）MQ-client提供拉模式，定時或者批量拉取，可以起到削平流量，下游自我保護的作用（MQ需要做的）
2）要想提升整體吞吐量，需要下游優化，例如批量處理等方式（消息接收方需要做的）
58到家架構優化具備整體性，需要通用服務和業務方一起優化升級。