流量削峰這個概念主要來自於互聯網的業務場景。例如春節火車票搶購，大量的用戶需要同一時間去搶購；又例如阿里的雙十一秒殺，短時間內上億的用戶涌入，瞬間流量巨大（高並發）。具體就是，300萬人在凌晨0點搶購一件數量只有500件的商品，最后能購買到的只有300萬人中的這500人。從業務上來說，這種秒殺活動是一種商業推廣的行為，當然是希望越多人參與越好，也就是希望在搶購之前，能有越來越多的人來瀏覽商品。但是在到達搶購時間，用戶真正開始下單的時候，承載秒殺的服務器卻不希望有幾百萬人同時發起搶購請求，因為服務器處理資源的能力是有限的，當出現請求峰值的時候就很容易造成服務器宕機，用戶無法訪問的情況出現。
這就好比出行的時候存在早高峰和晚高峰的情況，為了解決高峰問題，出行有錯峰限行的解決方案。同理，在線上的秒殺業務等場景，也需要類似的解決方案來解決流量峰值的問題，這就是流量削峰的由來。
實現流量削峰的方案
削峰從本質上來說，就是更多地延緩用戶請求，以及層層過濾用戶的訪問需求，遵從【最后落地到數據庫的請求數要盡量少】的原則。
1.消息隊列實現削峰
要對流量進行削峰，最容易想到的解決方案就是用消息隊列來緩沖瞬時流量，把同步的直接調用轉換成異步的間接推送，中間通過一個隊列在一端承接瞬時的流量洪峰，在另一端平滑地將消息推送出去。
消息隊列中間件主要解決應用耦合、異步消息、流量削峰等問題。常用的消息隊列系統有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、Me'taMQ和RocketMQ等。
在這里，消息隊列就像是水庫一樣，攔截上游的洪水，削減進入下游河道的洪峰流量，從而達到減免洪水災害的目的。
2.流量削峰漏斗：層層削峰
解決秒殺場景還可以對請求進行分層過濾，從而過濾掉一些無效的請求。分層過濾實際上就是采用漏斗式的設計來處理請求的，從高層至底層逐步過濾掉請求和數據。
分層過濾的核心思想是通過在不同的層次盡可能地過濾掉無效的請求，比如通過CDN過濾掉大量的圖片、靜態資源的請求，再通過類似Redis的分布式緩存來過濾請求等，也是典型的在上游攔截讀請求。
分層過濾的基本原則是要對數據進行基於時間的合理分片，過濾掉過期的失效請求；對寫請求做限流保護，將超出系統承載能力的請求過濾掉；涉及到的讀數據不做強一致性校驗，減少因為一致性校驗產生瓶頸的問題；對寫數據進行強一致性校驗，只保留最后的有效數據；最終，讓抵達漏斗最底端（數據庫）的請求成為有效請求，例如當用戶真實達到訂單和支付的流程是需要數據一致性的。
總結
1.對於秒殺業務這樣的高並發業務場景，最基本的原則就是要將請求攔截在系統的上游，降低下游的壓力。如果不在前端攔截，就很可能會造成數據庫讀寫鎖沖突，甚至導致死鎖，最終還有可能出現服務宕機的結果。
2.划分好動靜資源，靜態資源使用CDN進行服務分發，提高訪問性能。
3.充分利用緩存（Redis等），增加QPS，從而加大整個集群的吞吐量。
4.高峰流量是壓垮系統的一個重要原因，所以需要Kafka等消息隊列在一端承接瞬時的流量洪峰，在另一端平滑地將消息推送出去。
"心若沒有棲息的地方，到哪里都像在流浪。"