傳統架構，為何不是默認流控的？

站點與服務，服務與服務上下游之間，一般如何采用兩種通訊模式：

其一，RPC直接調用。

其二，MQ推送模式。其二，MQ推送模式。

畫外音：這也是MQ的默認模式。

這兩種模式，都可能造成流量沖擊：流量從端到站點，到服務，到數據庫，流量會一路透傳下來，引發雪崩。

舉個秒殺業務的栗子。

• 上游：端上發起搶購操作；
• 下游：完成秒殺業務邏輯（庫存檢查，庫存凍結，余額檢查，余額凍結，訂單生成，余額扣減，庫存扣減，生成流水，余額解凍，庫存解凍）；

上游每秒并發1W個請求，下游每秒只能并發處理2K個請求，如果流量直接透傳，會導致下游系統被壓垮。雪崩出現后，整體系統并發處理能力歸0。

如何避免雪崩，使得整體系統能夠保持在一個并發2K的處理水平？

有兩大類優化方向：

• 上游隊列緩沖，限速發送；
• 下游隊列緩沖，限速執行；

那哪種優化對架構改造最小？

下游隊列緩沖，限速執行，對系統改造最小。

如何改造？

上下游之間加一個MQ，采用拉模式：

MQ-reciever根據自己的處理能力，實施流控，就能達到保護自身的效果。并且這是MQ提供的通用功能，無需上下游修改代碼。

如果上游發送流量過大，MQ提供拉模式確實可以起到下游自我保護的作用，但會不會導致消息在MQ中堆積，導致全部超時？

下游處理過慢，確實可能會導致消息堆積，常見的有兩種處理方法：

• 治標法，提前判斷請求在隊列中的停留時間，如果超時，直接快速返回，這樣至少還能保證一部分請求不超時；
• 治本法，還是要優化下游業務系統，例如批量處理，才能從根本上提升吞吐量；

結論

削峰填谷，避免雪崩，實施流控，最小化升級：

• MQ要做的：MQ-client使用拉模式，定時或者批量拉取，可以起到削平流量，下游自我保護的作用；
• 業務系統要做的：優化處理吞吐量；

知其然，知其所以然。

思路比結論更重要。