前言

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

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了旺蒼免費建站歡迎大家使用！

一、秒殺中的削峰

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

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

1.消息隊列

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

但是，如果流量峰值持續(xù)時間達(dá)到了消息隊列的處理上限，消息隊列同樣也會被壓垮，這樣雖然保護(hù)了下游的系統(tǒng)，但是和直接把請求丟棄也沒多大的區(qū)別。就像遇到洪水爆發(fā)時，即使是有水庫恐怕也無濟(jì)于事。在這種情況下，我們要把“一步的操作”變成“兩步的操作”，其中增加的操作用來起到緩沖的作用，例如利用線程池加鎖等待、采用先進(jìn)先出、先進(jìn)后出等常用的內(nèi)存排隊算法。

2.答題器

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

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

3.數(shù)據(jù)過濾

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

這么做的目的是在讀系統(tǒng)中，盡量減少由于一致性校驗帶來的系統(tǒng)瓶頸，但是盡量將不影響性能的檢查條件提前，如用戶是否具有秒殺資格、商品狀態(tài)是否正常、用戶答題是否正確、秒殺是否已經(jīng)結(jié)束、是否非法請求等；在寫數(shù)據(jù)系統(tǒng)中，主要對寫的數(shù)據(jù)做一致性檢查，最后在數(shù)據(jù)庫層保證數(shù)據(jù)的最終準(zhǔn)確性。

二、秒殺中的服務(wù)性能優(yōu)化

服務(wù)端性能， 一般用QPS來衡量， 還有一個和QPS息息相關(guān)的是響應(yīng)時間， 它可以理解為服務(wù)器處理響應(yīng)的耗時。

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

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

真正對性能有影響的是CPU的執(zhí)行時間，因為CPU的執(zhí)行真正消耗了服務(wù)器的資源， 我們應(yīng)該致力于減少CPU的執(zhí)行時間。

對于Java系統(tǒng)可優(yōu)化的地方很多，除了常見的代碼優(yōu)化外，以下的內(nèi)容值得注意。

Java和通用的Web服務(wù)器相比，在處理大并發(fā)的HTTP請求時要弱一點， 所以一般我們都會對大流量的Web系統(tǒng)做靜態(tài)化改造，讓大部分請求和數(shù)據(jù)直接在Nginx服務(wù)器或者Web代理服務(wù)器上直接返回 ， 而Java層只需處理少量數(shù)據(jù)的動態(tài)請求。

針對這些請求， 我們可以使用以下手段進(jìn)行優(yōu)化：

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

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

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

像商品中的標(biāo)題和描述這些本身不變的數(shù)據(jù)，會在秒殺開始之前全量推送到緩存直到到秒殺結(jié)束。

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