秒殺系統流量削峯這事兒應該怎麼作？

若是你看過秒殺系統的流量監控圖的話，你會發現它是一條直線，就在秒殺開始那一秒是一條很直很直的線，這是由於秒殺請求在時間上高度集中於某一特定的時間點。這樣一來，就會致使一個特別高的流量峯值，它對資源的消耗是瞬時的。

可是對秒殺這個場景來講，最終可以搶到商品的人數是固定的，也就是說100人和10000人發起請求的結果都是同樣的，併發度越高，無效請求也越多。

可是從業務上來講，秒殺活動是但願更多的人來參與的，也就是開始以前但願有更多的人來刷頁面，可是真正開始下單時，秒殺請求並非越多越好。所以咱們能夠設計一些規則，讓併發的請求更多地延緩，並且咱們甚至能夠過濾掉一些無效請求。

爲何要削峯

爲何要削峯呢？或者說峯值會帶來哪些壞處？

咱們知道服務器的處理資源是恆定的，你用或者不用它的處理能力都是同樣的，因此出現峯值的話，很容易致使忙處處理不過來，閒的時候卻又沒有什麼要處理。可是因爲要保證服務質量，咱們的不少處理資源只能按照忙的時候來預估，而這會致使資源的一個浪費。

這就比如由於存在早高峯和晚高峯的問題，因此有了錯峯限行的解決方案。

削峯的存在，一是可讓服務端處理變得更加平穩，二是能夠節省服務器的資源成本。

針對秒殺這一場景，削峯從本質上來講就是更多地延緩用戶請求的發出，以便減小和過濾掉一些無效請求，它聽從「請求數要儘可能少」的原則。

今天，我就來介紹一下流量削峯的一些操做思路：排隊、答題、分層過濾。

這幾種方式都是無損（即不會損失用戶的發出請求）的實現方案，固然還有些有損的實現方案，包括咱們後面要介紹的關於穩定性的一些辦法，好比限流和機器負載保護等一些強制措施也能達到削峯保護的目的，固然這都是不得已的一些措施，所以就不歸類到這裏了。

排隊

要對流量進行削峯，最容易想到的解決方案就是用消息隊列來緩衝瞬時流量，把同步的直接調用轉換成異步的間接推送，中間經過一個隊列在一端承接瞬時的流量洪峯，在另外一端平滑地將消息推送出去。在這裏，消息隊列就像「水庫」同樣，攔蓄上游的洪水，削減進入下游河道的洪峯流量，從而達到減免洪水災害的目的。

用消息隊列來緩衝瞬時流量的方案，以下圖所示：

l消息隊列來緩衝瞬時流量

可是，若是流量峯值持續一段時間達到了消息隊列的處理上限，例如本機的消息積壓達到了存儲空間的上限，消息隊列一樣也會被壓垮，這樣雖然保護了下游的系統，可是和直接把請求丟棄也沒多大的區別。就像遇到洪水爆發時，即便是有水庫恐怕也無濟於事。

除了消息隊列，相似的排隊方式還有不少，例如：

• 利用線程池加鎖等待也是一種經常使用的排隊方式；
• 先進先出、先進後出等經常使用的內存排隊算法的實現方式；
• 把請求序列化到文件中，而後再順序地讀文件（例如基於MySQL binlog的同步機制）來恢復請求等方式。

能夠看到，這些方式都有一個共同特徵，就是把「一步的操做」變成「兩步的操做」，其中增長的一步操做用來起到緩衝的做用。

說到這裏你可能會說，這樣一來增長了訪問請求的路徑啊，並不符合咱們介紹的「4要1不要」原則。沒錯，的確看起來不太合理，可是若是不增長一個緩衝步驟，那麼在一些場景下系統極可能會直接崩潰，因此最終仍是須要你作出妥協和平衡。

答題

你是否還記得，最先期的秒殺只是純粹地刷新頁面和點擊購買按鈕，它是後來才增長了答題功能的。那麼，爲何要增長答題功能呢？

這主要是爲了增長購買的複雜度，從而達到兩個目的。

第一個目的是防止部分買家使用秒殺器在參加秒殺時做弊。2011年秒殺很是火的時候，秒殺器也比較猖獗，於是沒有達到全民參與和營銷的目的，因此係統增長了答題來限制秒殺器。增長答題後，下單的時間基本控制在2s後，秒殺器的下單比例也大大降低。答題頁面以下圖所示。

答題頁面

第二個目的其實就是延緩請求，起到對請求流量進行削峯的做用，從而讓系統可以更好地支持瞬時的流量高峯。這個重要的功能就是把峯值的下單請求拉長，從之前的1s以內延長到2s~10s。這樣一來，請求峯值基於時間分片了。這個時間的分片對服務端處理併發很是重要，會大大減輕壓力。

並且，因爲請求具備前後順序，靠後的請求到來時天然也就沒有庫存了，所以根本到不了最後的下單步驟，因此真正的併發寫就很是有限了。這種設計思路目前用得很是廣泛，如當年支付寶的「咻一咻」、微信的「搖一搖」都是相似的方式。

這裏，我重點說一下秒殺答題的設計思路。

秒殺答題

如上圖所示，整個秒殺答題的邏輯主要分爲3部分。

1. 題庫生成模塊，這個部分主要就是生成一個個問題和答案，其實題目和答案自己並不須要很複雜，重要的是可以防止由機器來算出結果，即防止秒殺器來答題。
2. 題庫的推送模塊，用於在秒殺答題前，把題目提早推送給詳情繫統和交易系統。題庫的推送主要是爲了保證每次用戶請求的題目是惟一的，目的也是防止答題做弊。
3. 題目的圖片生成模塊，用於把題目生成爲圖片格式，而且在圖片裏增長一些干擾因素。這也一樣是爲防止機器直接來答題，它要求只有人才能理解題目自己的含義。這裏還要注意一點，因爲答題時網絡比較擁擠，咱們應該把題目的圖片提早推送到CDN上而且要進行預熱，否則的話當用戶真正請求題目時，圖片可能加載比較慢，從而影響答題的體驗。

其實真正答題的邏輯比較簡單，很好理解：當用戶提交的答案和題目對應的答案作比較，若是經過了就繼續進行下一步的下單邏輯，不然就失敗。

咱們能夠把問題和答案用下面這樣的key來進行MD5加密：

• 問題key：userId+itemId+question_Id+time+PK
• 答案key：userId+itemId+answer+PK

驗證的邏輯以下圖所示：

答題的驗證邏輯

注意，這裏面的驗證邏輯，除了驗證問題的答案之外，還包括用戶自己身份的驗證，例如是否已經登陸、用戶的Cookie是否完整、用戶是否重複頻繁提交等。

除了作正確性驗證，咱們還能夠對提交答案的時間作些限制，例如從開始答題到接受答案要超過1s，由於小於1s是人爲操做的可能性很小，這樣也能防止機器答題的狀況。

分層過濾

前面介紹的排隊和答題要麼是少發請求，要麼對發出來的請求進行緩衝，而針對秒殺場景還有一種方法，就是對請求進行分層過濾，從而過濾掉一些無效的請求。分層過濾其實就是採用「漏斗」式設計來處理請求的，以下圖所示。

假如請求分別通過CDN、前臺讀系統（如商品詳情繫統）、後臺系統（如交易系統）和數據庫這幾層，那麼：

• 大部分數據和流量在用戶瀏覽器或者CDN上獲取，這一層能夠攔截大部分數據的讀取；
• 通過第二層（即前臺系統）時數據（包括強一致性的數據）儘可能得走Cache，過濾一些無效的請求；
• 再到第三層後臺系統，主要作數據的二次檢驗，對系統作好保護和限流，這樣數據量和請求就進一步減小；
• 最後在數據層完成數據的強一致性校驗。

這樣就像漏斗同樣，儘可能把數據量和請求量一層一層地過濾和減小了。

分層過濾的核心思想是：在不一樣的層次儘量地過濾掉無效請求，讓「漏斗」最末端的纔是有效請求。而要達到這種效果，咱們就必須對數據作分層的校驗。

分層校驗的基本原則是：

1. 將動態請求的讀數據緩存（Cache）在Web端，過濾掉無效的數據讀；
2. 對讀數據不作強一致性校驗，減小由於一致性校驗產生瓶頸的問題；
3. 對寫數據進行基於時間的合理分片，過濾掉過時的失效請求；
4. 對寫請求作限流保護，將超出系統承載能力的請求過濾掉；
5. 對寫數據進行強一致性校驗，只保留最後有效的數據。

分層校驗的目的是：

在讀系統中，儘可能減小因爲一致性校驗帶來的系統瓶頸，可是儘可能將不影響性能的檢查條件提早，如用戶是否具備秒殺資格、商品狀態是否正常、用戶答題是否正確、秒殺是否已經結束、是否非法請求、營銷等價物是否充足等；

在寫數據系統中，主要對寫的數據（如「庫存」）作一致性檢查，最後在數據庫層保證數據的最終準確性（如「庫存」不能減爲負數）。

總結一下

今天，我介紹瞭如何在網站面臨大流量衝擊時進行請求的削峯，並主要介紹了削峯的3種處理方式：

• 一個是經過隊列來緩衝請求，即控制請求的發出；
• 一個是經過答題來延長請求發出的時間，在請求發出後承接請求時進行控制，最後再對不符合條件的請求進行過濾；
• 最後一種是對請求進行分層過濾。

其中，隊列緩衝方式更加通用，它適用於內部上下游系統之間調用請求不平緩的場景，因爲內部系統的服務質量要求不能隨意丟棄請求，因此使用消息隊列能起到很好的削峯和緩衝做用。

而答題更適用於秒殺或者營銷活動等應用場景，在請求發起端就控制發起請求的速度，由於越到後面無效請求也會越多，因此配合後面介紹的分層攔截的方式，能夠更進一步減小無效請求對系統資源的消耗。

分層過濾很是適合交易性的寫請求，好比減庫存或者拼車這種場景，在讀的時候須要知道還有沒有庫存或者是否還有剩餘空座位。可是因爲庫存和座位又是不停變化的，因此讀的數據是否必定要很是準確呢？其實不必定，你能夠放一些請求過去，而後在真正減的時候再作強一致性保證，這樣既過濾一些請求又解決了強一致性讀的瓶頸。

不過，在削峯的處理方式上除了採用技術手段，其實還能夠採用業務手段來達到必定效果，例如在零點開啓大促的時候因爲流量太大致使支付系統阻塞，這個時候能夠採用發放優惠券、發起抽獎活動等方式，將一部分流量分散到其餘地方，這樣也能起到緩衝流量的做用。

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java高級交流：787707172，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。