秒殺業務場景如何削峯

流量削峯這個概念主要來自於互聯網的業務場景。例如春節火車票搶購，大量的用戶須要同一時間去搶購；又例如阿里的雙十一秒殺，短期內上億的用戶涌入，瞬間流量巨大（高併發）。具體就是，300萬人在凌晨0點搶購一件數量只有500件的商品，最後能購買到的只有300萬人中的這500人。從業務上來講，這種秒殺活動是一種商業推廣的行爲，固然是但願越多人蔘與越好，也就是但願在搶購以前，能有愈來愈多的人來瀏覽商品。可是在到達搶購時間，用戶真正開始下單的時候，承載秒殺的服務器卻不但願有幾百萬人同時發起搶購請求，由於服務器處理資源的能力是有限的，當出現請求峯值的時候就很容易形成服務器宕機，用戶沒法訪問的狀況出現。

這就比如出行的時候存在早高峯和晚高峯的狀況，爲了解決高峯問題，出行有錯峯限行的解決方案。同理，在線上的秒殺業務等場景，也須要相似的解決方案來解決流量峯值的問題，這就是流量削峯的由來。

實現流量削峯的方案

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

1.消息隊列實現削峯

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

消息隊列中間件主要解決應用耦合、異步消息、流量削峯等問題。經常使用的消息隊列系統有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、Me'taMQ和RocketMQ等。

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

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

解決秒殺場景還能夠對請求進行分層過濾，從而過濾掉一些無效的請求。分層過濾實際上就是採用漏斗式的設計來處理請求的，從高層至底層逐步過濾掉請求和數據。

分層過濾的核心思想是經過在不一樣的層次儘量地過濾掉無效的請求，好比經過CDN過濾掉大量的圖片、靜態資源的請求，再經過相似Redis的分佈式緩存來過濾請求等，也是典型的在上游攔截讀請求。

分層過濾的基本原則是要對數據進行基於時間的合理分片，過濾掉過時的失效請求；對寫請求作限流保護，將超出系統承載能力的請求過濾掉；涉及到的讀數據不作強一致性校驗，減小由於一致性校驗產生瓶頸的問題；對寫數據進行強一致性校驗，只保留最後的有效數據；最終，讓抵達漏斗最底端（數據庫）的請求成爲有效請求，例如當用戶真實達到訂單和支付的流程是須要數據一致性的。

總結

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

2.劃分好動靜資源，靜態資源使用CDN進行服務分發，提升訪問性能。

3.充分利用緩存（Redis等），增長QPS，從而加大整個集羣的吞吐量。

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

 

"心若沒有棲息的地方，到哪裏都像在流浪。"