MQ，很多的應(yīng)用場景，是消息的訂閱發(fā)布，是系統(tǒng)上下游的解耦，MQ的還有一個典型應(yīng)用場景是緩沖流量，削峰填谷，本文將簡單介紹下，MQ要怎么實現(xiàn)緩沖流量，削峰填谷。

站點與服務(wù)上下游之間，一般如何通訊？有兩種常見的方式。

一種是“直接調(diào)用”，通過RPC框架，上游直接調(diào)用下游。

一種是“MQ推送”，上游將消息發(fā)給MQ，MQ將消息推送給下游。

這兩種方式，能否緩存流量，能否削峰填谷？不能。不管采用“直接調(diào)用”還是“MQ推送”，都有一個缺點，下游消息接收方無法控制到達(dá)自己的流量，如果調(diào)用方不限速，很有可能把下游壓垮。

舉個栗子，秒殺業(yè)務(wù)：上游：發(fā)起下單操作。下游：完成秒殺業(yè)務(wù)邏輯（庫存檢查，庫存凍結(jié)，余額檢查，余額凍結(jié)，訂單生成，余額扣減，庫存扣減，生成流水，余額解凍，庫存解凍）。

上游下單業(yè)務(wù)簡單，每秒發(fā)起了10000個請求，下游秒殺業(yè)務(wù)復(fù)雜，每秒只能處理2000個請求，很有可能上游不限速的下單，導(dǎo)致下游系統(tǒng)被壓垮，引發(fā)雪崩。

如何避免下游被壓垮呢？為了避免雪崩，常見的優(yōu)化方案有兩種：（1）業(yè)務(wù)上游隊列緩沖，限速發(fā)送；（2）業(yè)務(wù)下游隊列緩沖，限速執(zhí)行；

不管哪種方案，都會引入業(yè)務(wù)的復(fù)雜性，有“緩沖流量”需求的系統(tǒng)都需要加入類似的機制，正所謂“通用痛點統(tǒng)一解決”，需要一個通用的機制解決這個問題。

能否通過MQ實現(xiàn)緩沖流量？可以，但需要簡單修改。

MQ要怎么改，能緩沖流量？由MQ-server推模式，升級為MQ-client拉模式。

MQ-client根據(jù)自己的處理能力，每隔一定時間，或者每次拉取若干條消息，實施流控，達(dá)到保護(hù)自身的效果。并且這是MQ提供的通用功能，無需上下游修改代碼。

如果上游發(fā)送流量過大，MQ提供拉模式確實可以起到下游自我保護(hù)的作用，會不會導(dǎo)致消息在MQ中堆積？下游MQ-client拉取消息，消息接收方能夠批量獲取消息，需要下游消息接收方進(jìn)行優(yōu)化，方能夠提升整體吞吐量，例如：批量寫。

結(jié)論（1）MQ-client提供拉模式，定時或者批量拉取，可以起到削平流量，下游自我保護(hù)的作用（MQ需要做的）；（2）要想提升整體吞吐量，需要下游優(yōu)化，例如批量處理等方式（消息接收方需要做的）；

架構(gòu)優(yōu)化要整體考慮，需要通用服務(wù)和業(yè)務(wù)方一起優(yōu)化升級。
編輯：hfy