秒殺業務場景如何削峰

流量削峰這個概念主要來自于網際網路的業務場景。例如春節火車票搶購，大量的使用者需要同一時間去搶購；又例如阿裡的雙十一秒殺，短時間内上億的使用者湧入，瞬間流量巨大（高并發）。具體就是，300萬人在淩晨0點搶購一件數量隻有500件的商品，最後能購買到的隻有300萬人中的這500人。從業務上來說，這種秒殺活動是一種商業推廣的行為，當然是希望越多人參與越好，也就是希望在搶購之前，能有越來越多的人來浏覽商品。但是在到達搶購時間，使用者真正開始下單的時候，承載秒殺的伺服器卻不希望有幾百萬人同時發起搶購請求，因為伺服器處理資源的能力是有限的，當出現請求峰值的時候就很容易造成伺服器當機，使用者無法通路的情況出現。

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

實作流量削峰的方案

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

1.消息隊列實作削峰

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

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

在這裡，消息隊列就像是水庫一樣，攔截上遊的洪水，削減進入下遊河道的洪峰流量，進而達到減免洪水災害的目的。

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

解決秒殺場景還可以對請求進行分層過濾，進而過濾掉一些無效的請求。分層過濾實際上就是采用漏鬥式的設計來處理請求的，從高層至底層逐漸過濾掉請求和資料。

分層過濾的核心思想是通過在不同的層次盡可能地過濾掉無效的請求，比如通過CDN過濾掉大量的圖檔、靜态資源的請求，再通過類似Redis的分布式緩存來過濾請求等，也是典型的在上遊攔截讀請求。

分層過濾的基本原則是要對資料進行基于時間的合理分片，過濾掉過期的失效請求；對寫請求做限流保護，将超出系統承載能力的請求過濾掉；涉及到的讀資料不做強一緻性校驗，減少因為一緻性校驗産生瓶頸的問題；對寫資料進行強一緻性校驗，隻保留最後的有效資料；最終，讓抵達漏鬥最底端（資料庫）的請求成為有效請求，例如當使用者真實達到訂單和支付的流程是需要資料一緻性的。

總結

1.對于秒殺業務這樣的高并發業務場景，最基本的原則就是要将請求攔截在系統的上遊，降低下遊的壓力。如果不在前端攔截，就很可能會造成資料庫讀寫鎖沖突，甚至導緻死鎖，最終還有可能出現服務當機的結果。

2.劃分好動靜資源，靜态資源使用CDN進行服務分發，提高通路性能。

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

你要去做一個大人，不要回頭，不要難過。