服務器資源
服務器的資源是恒定的，你用或者不用，它就在原地，處理能力不會改變。所以出現峰值的話，就很容易會導致忙到處理不過來，甚至讓服務器出現宕機情況，雖然大多數時候不會有過多的業務需要處理。但是為了保證服務質量，很多服務器的資源只能夠按照峰值的時候來設置，而這樣就會導致服務器資源的浪費。
特定的場景需要特定的設計
如12306的搶票、雙十一的購物，都會產生大量的請求同時涌向服務器，就會導致一個特別高的流量峰值，它對服務器資源的消耗是瞬時的。
為什么要流量削峰
流量削峰就好比因為存在早高峰和晚高峰的問題，所以有了錯峰限行的解決方案。
削峰的存在，一是可以讓服務端處理變得平穩，二是可以節省服務器的資源成本。
針對秒殺這一場景，削峰從本質上來說就是更多地去延緩用戶發出的請求，以便減少和過濾掉一些無效的請求，它遵從【請求數要盡量少】的原則。
削峰的主要思路
流量削峰主要有三種操作思路，一是排隊，二是答題，三是分層過濾，這三種方式都是無損（即不會損失用戶的請求發出）的實現方案。當然，還有些有損的實現方案，關于穩定性的一些方法，比如限流和機器負載保護等一些強制措施也能達到削峰保護的目的，只是這些都是一些不得已的措施。
排隊
要對流量進行削峰，最容易想到的解決方案就是用消息隊列來緩沖瞬時流量，把同步的直接調用轉換成異步的間接推送，中間通過一個隊列在一端承接瞬時的流量洪峰，另一端平滑地將消息推送出去。在這里，消息隊列就像一個水庫一樣，攔截上游的洪水，削減進入下游河道的洪峰流量，從而達到減免洪水災害的目的。
答題
答題功能，是為了增加購買的復雜度，從而達到兩個目的。
第一個目的是防止部分買家在參加秒殺的時候使用秒殺器作弊。在2011年秒殺非?；鸬臅r候，秒殺器也比較猖獗，因而并沒有達到全民參與和營銷推廣的目的，所以系統就增加了答題功能來限制秒殺器。在增加了答題功能后，下單的時間基本控制在2s后，秒殺器的下單比例也大大下降。
第二個目的是為了延緩請求，起到對請求流量進行削峰的作用，從而使系統能夠更好地支持瞬時的流量高峰。這個重要的功能就是把峰值的下單請求拉長，從先前的1s之內延長到2s~10s。這樣一來，請求峰值就基于時間分片了。這個時間的分片對服務端處理并發非常重要，會大大減輕壓力。而且由于請求具有先后順序，靠后的請求到來時自然就沒有庫存了，因此根本到不了最后的下單步驟，所以真正的并發寫就非常有限了。這種設計思路目前用得非常普遍，如支付寶的【咻一咻】和微信【搖一搖】，都是類似的方式。
整個秒殺答題功能的邏輯，主要可以分為3個部分。
1.題庫生成模塊。這個部分主要就是生成一個個問題和答案，題目和答案本身都不需要太復雜，重要的能防止由機器來算出結果，防止秒殺器答題。
2.題庫推送模塊。這個部分用于在秒殺答題前，把題目提前推送給詳情系統和交易系統。實時推送是為了保證每次用戶請求的題目是唯一的，防止答題作弊。
3.題目的圖片生成模塊，用于把題目生成為圖片格式，并且在圖片里增加一些干擾因素。這也同樣是為了防止機器直接來答題，它要求只有人才能理解題目本身的含義。這里還要注意一點，由于答題時網絡比較擁擠，應該把題目的圖片提前推送到CDN上并且要進行預熱，不然的話當用戶真正請求題目時，圖片可能加載比較慢，從而影響答題的體驗。
事實上，真正答題的邏輯是比較簡單的，比較容易理解。只要將用戶提交的答案與題目對應的答案做比較，比較通過則繼續進行下一步邏輯，否則就失敗。
分層過濾
假如請求分別經過CDN、前臺讀系統（如商品詳情系統）、后臺系統（如交易系統）和數據庫這層，那么，大部分數據和流量在用戶瀏覽器或CDN上獲取，這一層可以攔截大部分數據的讀?。唤涍^第二層（即前臺系統）時，數據（包括強一致性的數據）都盡量走Cache，過濾一些無效的請求；再到第三層的后臺系統，主要做數據的二次校驗，對系統做好保護和限流，這樣數據量和請求就進一步減少；最后在數據層完成數據的強一致性校驗就好了。
這樣的話，就像漏斗一樣，盡量把數據量和請求量一層一層地過濾和減少。
分層過濾的核心思想是在不同的層次盡可能地過濾掉無效的請求，讓漏斗最末端的才是有效請求。而要達到這種效果，我們就必須對數據做分層的校驗。
基本原則：
1.將動態請求的讀數據緩存（Cache）在Web端，過濾掉無效的數據讀取。
2.對讀數據不做強一致性校驗，減少因為一致性校驗產生性能瓶頸的問題。
3.對寫數據進行基于時間的合理分片，過濾掉過期的失效請求。
4.對寫請求做限流保護，將超出系統承載能力的請求過濾掉。
5.對寫數據進行強一致性校驗，只保留最后有效的數據。
分層校驗的目的是在讀系統中盡量減少由于一致性校驗帶來的系統瓶頸，但是盡量將不影響性能的檢查條件提前，比如用戶是否具有秒殺資格、商品狀態是否正常、用戶答題是否正確、秒殺是否已經結束、是否非法請求、營銷等價物是否充足等。而在寫數據系統中，主要對寫的數據（如庫存）做一致性檢查，最后在數據庫層保證數據的最終準確性（如庫存不能為負數）。
