如果你看過秒殺系統(tǒng)的流量監(jiān)控圖的話，你會發(fā)現(xiàn)它是一條直線，就在秒殺開始那一秒是一條很 直很直的線，這是因為秒殺請求在時間上高度集中于某一特定的時間點。這樣一來，就會導(dǎo)致一 個特別高的流量峰值，它對資源的消耗是瞬時的。

但是對秒殺這個場景來說，最終能夠搶到商品的人數(shù)是固定的，也就是說 100 人和 10000 人發(fā) 起請求的結(jié)果都是一樣的，并發(fā)度越高，無效請求也越多。

但是從業(yè)務(wù)上來說，秒殺活動是希望更多的人來參與的，也就是開始之前希望有更多的人來刷頁 面，但是真正開始下單時，秒殺請求并不是越多越好。因此我們可以設(shè)計一些規(guī)則，讓并發(fā)的請 求更多地延緩，而且我們甚至可以過濾掉一些無效請求。

為什么要削峰

為什么要削峰呢？

或者說峰值會帶來哪些壞處？

我們知道服務(wù)器的處理資源是恒定的，你用或者不用它的處理能力都是一樣的，所以出現(xiàn)峰值的 話，很容易導(dǎo)致忙到處理不過來，閑的時候卻又沒有什么要處理。但是由于要保證服務(wù)質(zhì)量，我 們的很多處理資源只能按照忙的時候來預(yù)估，而這會導(dǎo)致資源的一個浪費。

這就好比因為存在早高峰和晚高峰的問題，所以有了錯峰限行的解決方案。削峰的存在，一是可 以讓服務(wù)端處理變得更加平穩(wěn)，二是可以節(jié)省服務(wù)器的資源成本。針對秒殺這一場景，削峰從本 質(zhì)上來說就是更多地延緩用戶請求的發(fā)出，以便減少和過濾掉一些無效請求，它遵從“請求數(shù)要 盡量少”的原則。

今天，我就來介紹一下流量削峰的一些操作思路：排隊、答題、分層過濾。這幾種方式都是無損 （即不會損失用戶的發(fā)出請求）的實現(xiàn)方案，當(dāng)然還有些有損的實現(xiàn)方案，包括我們后面要介紹 的關(guān)于穩(wěn)定性的一些辦法，比如限流和機器負載保護等一些強制措施也能達到削峰保護的目的， 當(dāng)然這都是不得已的一些措施，因此就不歸類到這里了。

排隊

要對流量進行削峰，最容易想到的解決方案就是用消息隊列來緩沖瞬時流量，把同步的直接調(diào)用 轉(zhuǎn)換成異步的間接推送，中間通過一個隊列在一端承接瞬時的流量洪峰，在另一端平滑地將消息 推送出去。在這里，消息隊列就像“水庫”一樣， 攔蓄上游的洪水，削減進入下游河道的洪峰流 量，從而達到減免洪水災(zāi)害的目的。

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

但是，如果流量峰值持續(xù)一段時間達到了消息隊列的處理上限，例如本機的消息積壓達到了存儲 空間的上限，消息隊列同樣也會被壓垮，這樣雖然保護了下游的系統(tǒng)，但是和直接把請求丟棄也 沒多大的區(qū)別。就像遇到洪水爆發(fā)時，即使是有水庫恐怕也無濟于事。

除了消息隊列，類似的排隊方式還有很多，例如：

• 利用線程池加鎖等待也是一種常用的排隊方式；

• 先進先出、先進后出等常用的內(nèi)存排隊算法的實現(xiàn)方式；

• 把請求序列化到文件中，然后再順序地讀文件（例如基于 MySQL binlog 的同步機制）來恢 復(fù)請求等方式。

可以看到，這些方式都有一個共同特征，就是把“一步的操作”變成“兩步的操作”，其中增加 的一步操作用來起到緩沖的作用。

說到這里你可能會說，這樣一來增加了訪問請求的路徑啊，并不符合我們介紹的“4 要 1 不 要”原則。沒錯，的確看起來不太合理，但是如果不增加一個緩沖步驟，那么在一些場景下系統(tǒng) 很可能會直接崩潰，所以最終還是需要你做出妥協(xié)和平衡。

答題

你是否還記得，最早期的秒殺只是純粹地刷新頁面和點擊購買按鈕，它是后來才增加了答題功能 的。那么，為什么要增加答題功能呢？

這主要是為了增加購買的復(fù)雜度，從而達到兩個目的。

第一個目的是防止部分買家使用秒殺器在參加秒殺時作弊。2011 年秒殺非常火的時候，秒殺器 也比較猖獗，因而沒有達到全民參與和營銷的目的，所以系統(tǒng)增加了答題來限制秒殺器。增加答 題后，下單的時間基本控制在 2s 后，秒殺器的下單比例也大大下降。答題頁面如下圖所示。

第二個目的其實就是延緩請求，起到對請求流量進行削峰的作用，從而讓系統(tǒng)能夠更好地支持瞬 時的流量高峰。這個重要的功能就是把峰值的下單請求拉長，從以前的 1s 之內(nèi)延長到 2s~10s。這樣一來，請求峰值基于時間分片了。這個時間的分片對服務(wù)端處理并發(fā)非常重要，會大大減輕 壓力。而且，由于請求具有先后順序，靠后的請求到來時自然也就沒有庫存了，因此根本到不了 最后的下單步驟，所以真正的并發(fā)寫就非常有限了。這種設(shè)計思路目前用得非常普遍，如當(dāng)年支 付寶的“咻一咻”、微信的“搖一搖”都是類似的方式。

這里，我重點說一下秒殺答題的設(shè)計思路。

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

• 題庫生成模塊，這個部分主要就是生成一個個問題和答案，其實題目和答案本身并不需要很復(fù) 雜，重要的是能夠防止由機器來算出結(jié)果，即防止秒殺器來答題。

• 題庫的推送模塊，用于在秒殺答題前，把題目提前推送給詳情系統(tǒng)和交易系統(tǒng)。題庫的推送主 要是為了保證每次用戶請求的題目是唯一的，目的也是防止答題作弊。

• 題目的圖片生成模塊，用于把題目生成為圖片格式，并且在圖片里增加一些干擾因素。這也同 樣是為防止機器直接來答題，它要求只有人才能理解題目本身的含義。這里還要注意一點，由 于答題時網(wǎng)絡(luò)比較擁擠，我們應(yīng)該把題目的圖片提前推送到 CDN 上并且要進行預(yù)熱，不然的 話當(dāng)用戶真正請求題目時，圖片可能加載比較慢，從而影響答題的體驗。

其實真正答題的邏輯比較簡單，很好理解：當(dāng)用戶提交的答案和題目對應(yīng)的答案做比較，如果通 過了就繼續(xù)進行下一步的下單邏輯，否則就失敗。我們可以把問題和答案用下面這樣的 key 來進 行 MD5 加密：

問題 key：userId+itemId+question_Id+time+PK

答案 key：userId+itemId+answer+PK

驗證的邏輯如下圖所示：

注意，這里面的驗證邏輯，除了驗證問題的答案以外，還包括用戶本身身份的驗證，例如是否已 經(jīng)登錄、用戶的 Cookie 是否完整、用戶是否重復(fù)頻繁提交等。

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

分層過濾

前面介紹的排隊和答題要么是少發(fā)請求，要么對發(fā)出來的請求進行緩沖，而針對秒殺場景還有一 種方法，就是對請求進行分層過濾，從而過濾掉一些無效的請求。分層過濾其實就是采用“漏 斗”式設(shè)計來處理請求的，如下圖所示。

1、假如請求分別經(jīng)過 CDN、前臺讀系統(tǒng)（如商品詳情系統(tǒng)）、后臺系統(tǒng)（如交易系統(tǒng)）和數(shù)據(jù)庫 這幾層，那么：

2、大部分?jǐn)?shù)據(jù)和流量在用戶瀏覽器或者 CDN 上獲取，這一層可以攔截大部分?jǐn)?shù)據(jù)的讀取；

3、經(jīng)過第二層（即前臺系統(tǒng)）時數(shù)據(jù)（包括強一致性的數(shù)據(jù)）盡量得走 Cache，過濾一些無效的 請求；

4、再到第三層后臺系統(tǒng)，主要做數(shù)據(jù)的二次檢驗，對系統(tǒng)做好保護和限流，這樣數(shù)據(jù)量和請求就 進一步減少；

5、最后在數(shù)據(jù)層完成數(shù)據(jù)的強一致性校驗。

這樣就像漏斗一樣，盡量把數(shù)據(jù)量和請求量一層一層地過濾和減少了。

分層過濾的核心思想是：在不同的層次盡可能地過濾掉無效請求，讓“漏斗”最末端的才是有效 請求。而要達到這種效果，我們就必須對數(shù)據(jù)做分層的校驗。

分層校驗的基本原則是：

• 將動態(tài)請求的讀數(shù)據(jù)緩存（Cache）在 Web 端，過濾掉無效的數(shù)據(jù)讀；

• 對讀數(shù)據(jù)不做強一致性校驗，減少因為一致性校驗產(chǎn)生瓶頸的問題；

• 對寫數(shù)據(jù)進行基于時間的合理分片，過濾掉過期的失效請求；

• 對寫請求做限流保護，將超出系統(tǒng)承載能力的請求過濾掉；

• 對寫數(shù)據(jù)進行強一致性校驗 只保留最后有效的數(shù)據(jù)

總結(jié)一下

今天，我介紹了如何在網(wǎng)站面臨大流量沖擊時進行請求的削峰，并主要介紹了削峰的 3 種處理方 式：一個是通過隊列來緩沖請求，即控制請求的發(fā)出；一個是通過答題來延長請求發(fā)出的時間， 在請求發(fā)出后承接請求時進行控制，最后再對不符合條件的請求進行過濾；最后一種是對請求進 行分層過濾。

其中，隊列緩沖方式更加通用，它適用于內(nèi)部上下游系統(tǒng)之間調(diào)用請求不平緩的場景，由于內(nèi)部 系統(tǒng)的服務(wù)質(zhì)量要求不能隨意丟棄請求，所以使用消息隊列能起到很好的削峰和緩沖作用。而答題更適用于秒殺或者營銷活動等應(yīng)用場景，在請求發(fā)起端就控制發(fā)起請求的速度，因為越到 后面無效請求也會越多，所以配合后面介紹的分層攔截的方式，可以更進一步減少無效請求對系 統(tǒng)資源的消耗。

分層過濾非常適合交易性的寫請求，比如減庫存或者拼車這種場景，在讀的時候需要知道還有沒 有庫存或者是否還有剩余空座位。但是由于庫存和座位又是不停變化的，所以讀的數(shù)據(jù)是否一定 要非常準(zhǔn)確呢？其實不一定，你可以放一些請求過去，然后在真正減的時候再做強一致性保證， 這樣既過濾一些請求又解決了強一致性讀的瓶頸。

不過，在削峰的處理方式上除了采用技術(shù)手段，其實還可以采用業(yè)務(wù)手段來達到一定效果，例如 在零點開啟大促的時候由于流量太大導(dǎo)致支付系統(tǒng)阻塞，這個時候可以采用發(fā)放優(yōu)惠券、發(fā)起抽 獎活動等方式，將一部分流量分散到其他地方，這樣也能起到緩沖流量的作用。

總結(jié)

以上是生活随笔為你收集整理的秒杀系统流量削峰，这事应该怎么做？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。