流量削峰這個概念主要來自於網際網路的業務場景。例如春節火車票搶購，大量的使用者需要同一時間去搶購；又例如阿里的雙十一秒殺，短時間內上億的使用者湧入，瞬間流量巨大（高併發）。具體就是，300萬人在凌晨0點搶購一件數量只有500件的商品，最後能購買到的只有300萬人中的這500人。從業務上來說，這種秒殺活動是一種商業推廣的行為，當然是希望越多人參與越好，也就是希望在搶購之前，能有越來越多的人來瀏覽商品。但是在到達搶購時間，使用者真正開始下單的時候，承載秒殺的伺服器卻不希望有幾百萬人同時發起搶購請求，因為伺服器處理資源的能力是有限的，當出現請求峰值的時候就很容易造成伺服器宕機，使用者無法訪問的情況出現。
實現流量削峰的方案
削峰從本質上來說，就是更多地延緩使用者請求，以及層層過濾使用者的訪問需求，遵從【最後落地到資料庫的請求數要盡量少】的原則。
1.訊息佇列實現削峰
要對流量進行削峰，最容易想到的解決方案就是用訊息佇列來緩衝瞬時流量，把同步的直接呼叫轉換成非同步的間接推送，中間通過乙個佇列在一端承接瞬時的流量洪峰，在另一端平滑地將訊息推送出去。
訊息佇列中介軟體主要解決應用耦合、非同步訊息、流量削峰等問題。常用的訊息佇列系統有activemq、rabbitmq、zeromq、kafka、me'tamq和rocketmq等。
在這裡，訊息佇列就像是水庫一樣，攔截上游的洪水，削減進入下游河道的洪峰流量，從而達到減免洪水災害的目的。
2.流量削峰漏斗：層層削峰
解決秒殺場景還可以對請求進行分層過濾，從而過濾掉一些無效的請求。分層過濾實際上就是採用漏斗式的設計來處理請求的，從高層至底層逐步過濾掉請求和資料。
分層過濾的核心思想是通過在不同的層次盡可能地過濾掉無效的請求，比如通過cdn過濾掉大量的、靜態資源的請求，再通過類似redis的分布式快取來過濾請求等，也是典型的在上游攔截讀請求。
分層過濾的基本原則是要對資料進行基於時間的合理分片，過濾掉過期的失效請求；對寫請求做限流保護，將超出系統承載能力的請求過濾掉；涉及到的讀資料不做強一致性校驗，減少因為一致性校驗產生瓶頸的問題；對寫資料進行強一致性校驗，只保留最後的有效資料；最終，讓抵達漏斗最底端（資料庫）的請求成為有效請求，例如當使用者真實達到訂單和支付的流程是需要資料一致性的。
總結
1.對於秒殺業務這樣的高併發業務場景，最基本的原則就是要將請求攔截在系統的上游，降低下游的壓力。如果不在前端攔截，就很可能會造成資料庫讀寫鎖衝突，甚至導致死鎖，最終還有可能出現服務宕機的結果。
2.劃分好動靜資源，靜態資源使用cdn進行服務分發，提高訪問效能。
3.充分利用快取（redis等），增加qps，從而加大整個集群的吞吐量。
4.高峰流量是壓垮系統的乙個重要原因，所以需要kafka等訊息佇列在一端承接瞬時的流量洪峰，在另一端平滑地將訊息推送出去。
"心若沒有棲息的地方，到**都像在流浪。"
如何解決秒殺業務的削峰場景
主要是還是來自於網際網路的業務場景，例如，馬上即將開始的春節火車票搶購，大量的使用者需要同一時間去搶購 以及大家熟知的阿里雙11秒殺，短時間上億的使用者湧入，瞬間流量巨大 高併發 比如 200萬人準備在凌晨12 00準備搶購一件商品，但是商品的數量缺是有限的100 500件左右。這樣真實能購買到該件...
秒殺系統 流量削峰技術 秒殺令牌
生成秒殺令牌 override public string generatesecondkilltoken integer promoid,integer itemid,integer userid if promomodel.getstarttime isafternow else if prom...
高併發 秒殺業務場景詳解
一 秒殺場景的特點 秒殺的商品具有 低 庫存有限 定時開始的特點，因此秒殺場景最大的特點就是高併發。數以千萬的使用者的流量集中在某個時間點上 即秒殺開始時 給後端伺服器造成很大壓力，如果不能進行有效削峰 限流，所有請求一次性打到某一台伺服器或資料庫上，必然造成服務的不可用，給使用者造成不良體驗。二 ...