一、流量削峰的場景
流量高峰主要是用於應對大流量的業務，短時間內大量的用戶搶占有限的商品或資源所發生的高並發場景。比如我們春節火車票的搶購，上億用戶在線搶票，雙十一瘋狂的女人在線剁手；某促銷活動幾百萬人同時在某個時間點搶購有限數量的折扣商品等。以促銷活動為例，實際上真實能購買到該件商品的用戶也只有固定的幾百人(商品實際數量),但是從業務上來說，秒殺活動是希望更多的人來參與，也就是搶購之前希望有越來越多的人來看購買商品(大部分的高並發都是業務噱頭，甚至可以通過業務來避免)。用戶開始真正下單時，秒殺的服務器后端卻不希望同時有幾百萬人同時發起搶購請求(無法承擔)。我們知道服務器的處理資源是有限的，請求與業務處理都是需要消耗資源,所以當瞬間請求過多的時候，服務器的資源都會傾斜向處理接收請求，那么留給業務處理的資源也就少了,當瞬間請求到達一定的峰值時，便很容易導致請求阻塞，用戶響應延遲，服務器宕機，系統崩潰等一系列問題出現。這就好比出行的時候存在早高峰和晚高峰的問題，為了解決這個問題，出行就有了錯峰限行的解決方案。同理，在線上的秒殺等業務場景，也需要類似的解決方案，需要平安度過大批量數據並發搶購帶來的流量峰值的問題，這就是流量削峰的由來。總結：有限的資源，超額的負載，系統不堪重負!
二、怎樣來實現流量削峰方案
削峰從本質上來說是更多地延緩用戶請求，以及層層過濾用戶的訪問需求，遵從“最后落地到數據庫的請求數要盡量少”的原則。
1. 消息隊列解決削峰
要對流量進行削峰，最通用的解決方案就是用消息隊列來緩沖瞬時流量，把同步的直接調用轉換成異步的間接推送,中間通過一個隊列在一端承接瞬時的流量洪峰，在另一端平滑地將消息推送出去，消息隊列本質就是一個緩沖區，用於延緩數據請求。在這里，消息隊列就像“水庫”一樣，攔蓄上游的洪水，削減進入下游河道的洪峰流量，從而達到減免洪水災害的目的。
消息隊列中間件主要解決應用耦合，異步消息， 流量削鋒等問題。常用消息隊列系統：目前在並發生產環境，使用較多的消息隊列有 ActiveMQ、RabbitMQ、 ZeroMQ、Kafka、MetaMQ、RocketMQ等。其中RabbitMQ幾乎是各大並發系統的首選!
2. 流量削峰漏斗：層層削峰
針對秒殺場景還有一種方法，就是對請求進行分層過濾，從而過濾掉一些無效的請求。分層過濾可以類比為“漏斗”式設計來處理請求的，如下圖所示：
這樣就像漏斗一樣，盡量把數據量和請求量一層一層地過濾和減少了。
1）分層過濾的核心思想 通過在不同的層次盡可能地過濾掉無效請求。在不影響用戶體驗的情況下降低用戶的請求頻率。通過CDN過濾掉大量的圖片，靜態資源的請求。通過類似Redis這樣的高性能內存數據庫進行緩存處理，過濾請求等上在游攔截讀請求，從而盡量減少數據庫的命中率。
2）分層過濾的基本原則 對寫數據進行基於時間的合理分片，過濾掉過期的失效請求。對寫請求做限流保護，將超出系統承載能力的請求過濾掉。涉及到的讀數據不做強一致性校驗，減少因為一致性校驗產生瓶頸的問題。對寫數據進行強一致性校驗，只保留最后有效的數據。針對熱點數據進行做好緩存處理並通過合理方式確保一致性。最終，讓“漏斗”最末端(數據庫)的才是有效請求。例如：當用戶真實達到訂單和支付的流程，這個是需要數據強一致性的。
三、總結
1.對於秒殺這樣的高並發場景業務，最基本的原則就是將請求攔截在系統上游，降低下游壓力，減少對數據庫的訪問。
2.划分好動靜資源，靜態資源使用CDN進行服務分發。
3.充分利用緩存(redis等)：增加QPS，從而加大整個集群的吞吐量。
4.高峰值流量是壓垮系統很重要的原因，所以在需要時可以利用Kafka等消息隊列在一端承接瞬時的流量洪峰，在另一端平滑地將消息推送出去。
利用高可用的性能組件進行緩存熱點數據，減少對數據庫的訪問。