如何解決秒殺業務的削峰場景

主要是還是來自於網際網路的業務場景，例如，馬上即將開始的春節火車票搶購，大量的使用者需要同一時間去搶購；以及大家熟知的阿里雙11秒殺，

短時間上億的使用者湧入，瞬間流量巨大（高併發），比如：200萬人準備在凌晨12:00準備搶購一件商品，但是商品的數量缺是有限的100-500件左右。

這樣真實能購買到該件商品的使用者也只有幾百人左右，但是從業務上來說，秒殺活動是希望更多的人來參與，也就是搶購之前希望有越來越多的人來看購買商品。

但是，在搶購時間達到後，使用者開始真正下單時，秒殺的伺服器後端缺不希望同時有幾百萬人同時發起搶購請求。

我們都知道伺服器的處理資源是有限的，所以出現峰值的時候，很容易導致伺服器宕機，使用者無法訪問的情況出現。

這就好比出行的時候存在早高峰和晚高峰的問題，為了解決這個問題，出行就有了錯峰限行的解決方案。

削峰從本質上來說就是更多地延緩使用者請求，以及層層過濾使用者的訪問需求，遵從「最後落地到資料庫的請求數要盡量少」的原則。

1.訊息佇列解決削峰

要對流量進行削峰，最容易想到的解決方案就是用訊息佇列來緩衝瞬時流量，把同步的直接呼叫轉換成非同步的間接推送，中間通過乙個佇列在一端承接瞬時的流量洪峰，在另一端平滑地將訊息推送出去。

訊息佇列中介軟體主要解決應用耦合，非同步訊息，流量削鋒等問題。常用訊息佇列系統：目前在生產環境，使用較多的訊息佇列有 activemq、rabbitmq、 zeromq、kafka、metamq、rocketmq 等。

在這裡，訊息佇列就像「水庫」一樣，攔蓄上游的洪水，削減進入下游河道的洪峰流量，從而達到減免洪水災害的目的。

2.流量削峰漏斗：層層削峰

針對秒殺場景還有一種方法，就是對請求進行分層過濾，從而過濾掉一些無效的請求。

分層過濾其實就是採用「漏斗」式設計來處理請求的，如下圖所示：

這樣就像漏斗一樣，盡量把資料量和請求量一層一層地過濾和減少了。

1）分層過濾的核心思想

2）分層過濾的基本原則

最終，讓「漏斗」最末端(資料庫)的才是有效請求。例如：當使用者真實達到訂單和支付的流程，這個是需要資料強一致性的。

1.對於秒殺這樣的高併發場景業務，最基本的原則就是將請求攔截在系統上游，降低下游壓力。如果不在前端攔截很可能造成資料庫(mysql、oracle等)讀寫鎖衝突，甚至導致死鎖，最終還有可能出現雪崩等場景。

2.劃分好動靜資源，靜態資源使用cdn進行服務分發。

3.充分利用快取(redis等)：增加qps，從而加大整個集群的吞吐量。

4.高峰值流量是壓垮系統很重要的原因，所以需要rocketmq訊息佇列在一端承接瞬時的流量洪峰，在另一端平滑地將訊息推送出去。