前言
秒殺請求在高度集中在某一個時間點，這樣一來，就會導致一 個特別高的流量峰值，它對資源的消耗是瞬時的 ，能夠搶到商品的人數是有限的，也就是說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，你需要劃分成動態資料和靜態資料，
像商品中的標題和描述這些本身不變的資料，會在秒殺開始之前全量推送到快取直到到秒殺結束，
像庫存這類動態資料的方式快取一定時間，失效后再去快取拉取最新的，你可能還會有疑問：像庫存這種頻繁更新的資料，一旦資料不一致，會不會導致超賣? 這就要用到前面介紹的讀資料的分層原則了，讀的場景可以允許一定的臟資料，因為這里的誤判只會導致少量原本無庫存的下單請求被誤認為有庫存，可以等到真正寫資料時再保證最終的一致性，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/509153.html
標籤：其他
下一篇：那些技術實戰中的架構設計方法