前言

秒殺請求在高度集中在某一個時間點。這樣一來，就會導致一 個特別高的流量峰值，它對資源的消耗是瞬時的 。能夠搶到商品的人數是有限的，也就是說10人和1000人發 起請求的結果都是一樣的。也就是說真正開始下單時，秒殺請求並不是越多越好。

一、秒殺中的削峰

由於伺服器的處理資源是恆定的，用或者不用它的處理能力都是一樣的，出現峰值的話，很容易導致忙到處理不過來，閑的時候卻又沒有什麼要處理。為了保證服務質量，很多處理資源只能按照忙時預估，而這會導致資源浪費。 削峰可以讓服務端處理變得更加平穩，還可以節省伺服器的資源成本。針對秒殺這一場景，削峰從本質上來說就是更多地延緩用戶請求的發出，以便減少和過濾掉一些無效請求。

常見秒殺流量削峰的一些操作思路：消息隊列、答題器、數據過濾。

1.消息隊列

其中最容易想到的解決方案就是用消息隊列來緩衝瞬時流量，把同步的直接調用轉換成非同步的間接推送，通過隊列在一端承接瞬時的流量洪峰，在另一端平滑地將消息推送出去，在這裡，消息隊列就像“水庫"一樣，攔蓄上游的洪水，削減進入下游的洪峰流量。

但是，如果流量峰值持續時間達到了消息隊列的處理上限，消息隊列同樣也會被壓垮，這樣雖然保護了下游的系統，但是和直接把請求丟棄也沒多大的區別。就像遇到洪水爆發時，即使是有水庫恐怕也無濟於事。在這種情況下，我們要把“一步的操作”變成“兩步的操作”，其中增加的操作用來起到緩衝的作用，例如利用線程池加鎖等待、採用先進先出、先進後出等常用的記憶體排隊演算法。

2.答題器

添加答題器第一個目的是防止部分買家使用秒殺器在參加秒殺時作弊，第二個目的就是延緩請求，起到削峰的作用。把請求的時間從瞬時延長到了幾秒，這樣會大大減輕對伺服器的壓力。而且後續請求到達伺服器時已經沒有庫存了，真正的併發處理就很有限了。

答題器生成的題目不需要很複雜，為了防止被破解可以添加圖片噪點。同時在CDN上緩存圖片，避免成為秒殺活動中的短板，影響用戶體驗。

3.數據過濾

這裡提到的數據過濾有點像某些企業在招聘時，把簡歷隨機抽出一部分扔掉一樣，只不過抽取的過程可以設置一定的規則，過濾掉那些無效的請求。在不同的處理層根據不同的規則有效的過濾，例如對寫數據進行基於時間的合理分片，過濾掉過期的失效請求；對寫數據進行強一致性校驗，只保留最後有效的數據。

這麼做的目的是在讀系統中，儘量減少由於一致性校驗帶來的系統瓶頸，但是儘量將不影響性能的檢查條件提前，如用戶是否具有秒殺資格、商品狀態是否正常、用戶答題是否正確、秒殺是否已經結束、是否非法請求等；在寫數據系統中，主要對寫的數據做一致性檢查，最後在資料庫層保證數據的最終準確性。

二、秒殺中的服務性能優化

服務端性能， 一般用QPS來衡量， 還有一個和QPS息息相關的是響應時間， 它可以理解為伺服器處理響應的耗時。

正常情況下響應時間越短， 一秒鐘處理的請求數(QPS) 自然也就會越多， 這在單線程處理的情況下看起來是線性的關係，即我們只要把每個請求的響應時間降到最低，那麼性能就會最高。

這個兩個因素到底會造成什麼樣的影響？首先， 我們先來看看響應時間和QPS的關係，對於大部分的Web系統而言響應時間一般都是由CPU執行時間和線程等待時間組成，也許你會說為什麼不去減少這種等待時間，其實減少線程等待時間對提升性能的影響沒有我們想象得那麼大， 這點在很多代理伺服器上可以做驗證，如果代理伺服器本身沒有CPU消耗， 我們在每次給代理伺服器代理的請求加個延時， 即增加響應時間，這對代理伺服器本身的吞吐量並沒有多大的影響，因為代理伺服器本身的資源並沒有被消耗。

真正對性能有影響的是CPU的執行時間， 因為CPU的執行真正消耗了伺服器的資源， 我們應該致力於減少CPU的執行時間。

對於Java系統可優化的地方很多，除了常見的代碼優化外，以下的內容值得註意。

Java和通用的Web伺服器相比，在處理大併發的HTTP請求時要弱一點， 所以一般我們都會對大流量的Web系統做靜態化改造，讓大部分請求和數據直接在Nginx伺服器或者Web代理伺服器上直接返回 ， 而Java層只需處理少量數據的動態請求。

針對這些請求， 我們可以使用以下手段進行優化：

1.直接使用Servlet處理請求， 避免使用傳統的MVC框架， 這樣可以繞過一大堆複雜且用處不大的處理邏輯， 直接輸出流數據。使用resp.getOutputStream)而不是resp.get Writer函數， 可以省掉一些不變字元數據的編碼， 從而提升性能。

2.數據輸出時推薦使用JSON而不是模板引擎來輸出頁面。

3.集中式緩存為了保證命中率一般都會採用一致性Hash， 所以同一個key會落到同一臺機器上。那麼，該如何徹底解決單點的瓶頸呢? 答案是採用應用層的Local Cache。你需要劃分成動態數據和靜態數據。

像商品中的標題和描述這些本身不變的數據，會在秒殺開始之前全量推送到緩存直到到秒殺結束。

像庫存這類動態數據的方式緩存一定時間，失效後再去緩存拉取最新的。你可能還會有疑問：像庫存這種頻繁更新的數據，一旦數據不一致，會不會導致超賣? 這就要用到前面介紹的讀數據的分層原則了，讀的場景可以允許一定的臟數據，因為這裡的誤判只會導致少量原本無庫存的下單請求被誤認為有庫存，可以等到真正寫數據時再保證最終的一致性。