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）要想提高總體吞吐量，須要下游優化，例如批量處理等方式（消息接收方須要作的）