秒殺系統中流量削峰場景應該怎麼解決?

Java丨晨發表於2019-04-28

前言

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

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

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

為什麼要削峰

為什麼要削峰呢?或者說峰值會帶來哪些壞處?

我們知道伺服器的處理資源是恆定的,你用或者不用它的處理能力都是一樣的,所以出現峰值的 話,很容易導致忙到處理不過來,閒的時候卻又沒有什麼要處理。但是由於要保證服務質量,我 們的很多處理資源只能按照忙的時候來預估,而這會導致資源的一個浪費。

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

今天,我就來介紹一下流量削峰的一些操作思路:排隊、答題、分層過濾。這幾種方式都是無損 (即不會損失使用者的發出請求)的實現方案,當然還有些有損的實現方案,包括我們後面要介紹 的關於穩定性的一些辦法,比如限流和機器負載保護等一些強制措施也能達到削峰保護的目的, 當然這都是不得已的一些措施,因此就不歸類到這裡了。

排隊

要對流量進行削峰,最容易想到的解決方案就是用訊息佇列來緩衝瞬時流量,把同步的直接呼叫 轉換成非同步的間接推送,中間通過一個佇列在一端承接瞬時的流量洪峰,在另一端平滑地將訊息 推送出去。在這裡,訊息佇列就像“水庫”一樣, 攔蓄上游的洪水,削減進入下游河道的洪峰流 量,從而達到減免洪水災害的目的。

用訊息佇列來緩衝瞬時流量的方案,如下圖所示:

秒殺系統中流量削峰場景應該怎麼解決?

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

除了訊息佇列,類似的排隊方式還有很多,例如:

  1. 利用執行緒池加鎖等待也是一種常用的排隊方式;

  2. 先進先出、先進後出等常用的記憶體排隊演算法的實現方式;

  3. 把請求序列化到檔案中,然後再順序地讀檔案(例如基於 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 是人為操作的可能性很小,這樣也能防止機器答題的情況。

分層過濾

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

秒殺系統中流量削峰場景應該怎麼解決?
  1. 假如請求分別經過 CDN、前臺讀系統(如商品詳情繫統)、後臺系統(如交易系統)和資料庫 這幾層,那麼:

  2. 大部分資料和流量在使用者瀏覽器或者 CDN 上獲取,這一層可以攔截大部分資料的讀取;

  3. 經過第二層(即前臺系統)時資料(包括強一致性的資料)儘量得走 Cache,過濾一些無效的 請求;

  4. 再到第三層後臺系統,主要做資料的二次檢驗,對系統做好保護和限流,這樣資料量和請求就 進一步減少;

  5. 最後在資料層完成資料的強一致性校驗。

這樣就像漏斗一樣,儘量把資料量和請求量一層一層地過濾和減少了。

分層過濾的核心思想是:在不同的層次儘可能地過濾掉無效請求,讓“漏斗”最末端的才是有效 請求。而要達到這種效果,我們就必須對資料做分層的校驗。

分層校驗的基本原則是:

  1. 將動態請求的讀資料快取(Cache)在 Web 端,過濾掉無效的資料讀;

  2. 對讀資料不做強一致性校驗,減少因為一致性校驗產生瓶頸的問題;

  3. 對寫資料進行基於時間的合理分片,過濾掉過期的失效請求;

  4. 對寫請求做限流保護,將超出系統承載能力的請求過濾掉;

  5. 對寫資料進行強一致性校驗 只保留最後有效的資料

總結

紹瞭如何在網站面臨大流量衝擊時進行請求的削峰,並主要介紹了削峰的3種處理方式:

  1. 一個是通過佇列來緩衝請求,即控制請求的發出;
  2. 一個是通過答題來延長請求發出的時間, 在請求發出後承接請求時進行控制,最後再對不符合條件的請求進行過濾;
  3. 最後一種是對請求進 行分層過濾。

其中,佇列緩衝方式更加通用,它適用於內部上下游系統之間呼叫請求不平緩的場景,由於內部 系統的服務質量要求不能隨意丟棄請求,所以使用訊息佇列能起到很好的削峰和緩衝作用。 而答題更適用於秒殺或者營銷活動等應用場景,在請求發起端就控制發起請求的速度,因為越到 後面無效請求也會越多,所以配合後面介紹的分層攔截的方式,可以更進一步減少無效請求對系 統資源的消耗。

分層過濾非常適合交易性的寫請求,比如減庫存或者拼車這種場景,在讀的時候需要知道還有沒 有庫存或者是否還有剩餘空座位。但是由於庫存和座位又是不停變化的,所以讀的資料是否一定 要非常準確呢?其實不一定,你可以放一些請求過去,然後在真正減的時候再做強一致性保證, 這樣既過濾一些請求又解決了強一致性讀的瓶頸。

不過,在削峰的處理方式上除了採用技術手段,其實還可以採用業務手段來達到一定效果,例如 在零點開啟大促的時候由於流量太大導致支付系統阻塞,這個時候可以採用發放優惠券、發起抽 獎活動等方式,將一部分流量分散到其他地方,這樣也能起到緩衝流量的作用。


相關文章