高併發架構系列：什麼是流量削峯？如何解決秒殺業務的削峯場景

流量削峯的由來

主要是仍是來自於互聯網的業務場景，例如，立刻即將開始的春節火車票搶購，大量的用戶須要同一時間去搶購；以及你們熟知的阿里雙11秒殺， 短期上億的用戶涌入，瞬間流量巨大（高併發），好比：200萬人準備在凌晨12:00準備搶購一件商品，可是商品的數量缺是有限的100-500件左右。

這樣真實能購買到該件商品的用戶也只有幾百人左右， 可是從業務上來講，秒殺活動是但願更多的人來參與，也就是搶購以前但願有愈來愈多的人來看購買商品。

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

咱們都知道服務器的處理資源是有限的，因此出現峯值的時候，很容易致使服務器宕機，用戶沒法訪問的狀況出現。

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

同理，在線上的秒殺等業務場景，也須要相似的解決方案，須要平安度過同時搶購帶來的流量峯值的問題，這就是流量削峯的由來。

怎樣來實現流量削峯方案

削峯從本質上來講就是更多地延緩用戶請求，以及層層過濾用戶的訪問需求，聽從「最後落地到數據庫的請求數要儘可能少」的原則。

1.消息隊列解決削峯

要對流量進行削峯，最容易想到的解決方案就是用消息隊列來緩衝瞬時流量，把同步的直接調用轉換成異步的間接推送，中間經過一個隊列在一端承接瞬時的流量洪峯，在另外一端平滑地將消息推送出去。

消息隊列中間件主要解決應用耦合，異步消息， 流量削鋒等問題。經常使用消息隊列系統：目前在生產環境，使用較多的消息隊列有 ActiveMQ、RabbitMQ、 ZeroMQ、Kafka、MetaMQ、RocketMQ 等。

在這裏，消息隊列就像「水庫」同樣，攔蓄上游的洪水，削減進入下游河道的洪峯流量，從而達到減免洪水災害的目的。

具體的消息隊列MQ選型和應用場景能夠參考(點擊查看)：高併發架構系列：詳解分佈式之消息隊列的特色、選型、及應用場景

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

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

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

這樣就像漏斗同樣，儘可能把數據量和請求量一層一層地過濾和減小了。

1）分層過濾的核心思想

• 經過在不一樣的層次儘量地過濾掉無效請求。
• 經過CDN過濾掉大量的圖片，靜態資源的請求。
• 再經過相似Redis這樣的分佈式緩存，過濾請求等就是典型的在上游攔截讀請求。

2）分層過濾的基本原則

• 對寫數據進行基於時間的合理分片，過濾掉過時的失效請求。
• 對寫請求作限流保護，將超出系統承載能力的請求過濾掉。
• 涉及到的讀數據不作強一致性校驗，減小由於一致性校驗產生瓶頸的問題。
• 對寫數據進行強一致性校驗，只保留最後有效的數據。

最終，讓「漏斗」最末端(數據庫)的纔是有效請求。例如：當用戶真實達到訂單和支付的流程，這個是須要數據強一致性的。

總結

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

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

3.充分利用緩存(redis等)：增長QPS，從而加大整個集羣的吞吐量。

4.高峯值流量是壓垮系統很重要的緣由，因此須要Kafka等消息隊列在一端承接瞬時的流量洪峯，在另外一端平滑地將消息推送出去。

---

原文連接