淺談秒殺系統架構設計

秒殺是電子商務網站常見的一種營銷手段。

原則

• 不要整個系統宕機。
• 即便系統故障，也不要將錯誤數據展現出來。
• 儘可能保持公平公正。

實現效果

• 秒殺開始前，搶購按鈕爲活動未開始。
• 秒殺開始時，搶購按鈕能夠點擊下單。
• 秒殺結束後，按鈕按鈕變成秒殺已結束。

技術攻關

• 短期內的大訪問量對現有網站業務形成的衝擊。

  秒殺是一個網站營銷的一個附加活動，時間短，併發量大。

  若是和網站原有應用部署在一塊兒，必然會對現有業務形成衝擊，稍有不慎可能致使整個網站癱瘓。

• 高併發下對服務器數據庫形成的極大負載壓力。

  用戶秒殺開始前，經過不斷刷新瀏覽器來保證不會錯過秒殺活動。

  頻繁的訪問程序、數據庫會對應用服務器和數據庫服務器形成負載壓力。

• 網絡帶寬的問題比超過平時好多倍。

  若是秒殺頁面的大小爲200K，若是最大併發數爲10000次，那麼須要的網絡和服務器帶寬是2G（200K×10000）。

  這些網絡帶寬是由於秒殺活動新增的，超過網站平時使用的帶寬。

• 避免直接下單。

  秒殺的遊戲規則是到了秒殺才能開始對商品下單購買，在此時間點以前，只能瀏覽信息不可下單。

  而下單頁面也是一個普通的URL，若是獲得這個URL，不用等到秒殺開始就能夠下單了。

應對策略

• 秒殺系統獨立部署

  爲了不短期內的大訪問量對現有網站業務形成的衝擊，能夠將秒殺系統獨立部署。

  若是須要還能夠使用獨立域名，使其與網站徹底隔離。

  即便秒殺系統崩潰了，也不會對網站形成影響。

• 秒殺商品頁面靜態化

  將商品描述、參數、詳情，所有寫到一個靜態頁面，不用進行程序的邏輯處理，不需訪問數據庫。

  不用部署動態的服務器和數據庫服務器。

• 租借秒殺活動的網絡帶寬

  由於秒殺新增的網絡帶寬，必須和運營商從新購買或租借帶寬。

  爲了減輕服務器的壓力，須要將秒殺商品頁面緩存在CDN,一樣CDN服務器也須要臨時租借帶寬。

• 動態生成隨機下單頁面的URL

  爲了不用戶直接訪問下單URL,須要將URL動態化，用隨機數做爲參數，只能秒殺開始的時候才生成。

架構設計

• 如何控制秒殺商品頁面搶購按鈕的可用/禁用。

  購買按鈕只有在秒殺開始的時候才能點亮，在此以前是灰色的，顯示活動未開始。
  
  若是頁面是動態生成的，每次刷新都要請求服務器，那麼勢必形成服務端的負載壓力。
  
  若是頁面是靜態頁面的話，能夠將頁面緩存在CDN，反向代理服務器上，甚至用戶瀏覽器上。
  
  可是這樣，秒殺開始時，用戶刷新頁面，根本請求不到應用服務器。
  
  解決方案：
  
  使用JS腳本控制，在頁面中引用一個JS文件(文件極小)，可是該文件不要被緩存。
  
  該JS的做用是，包含秒殺開始標誌，修改樣式，生成下單頁面的URL及隨機參數。
  
  該JS文件不被緩存的作法：xxx.js?v=隨機數。
  
  會有一臺服務器進行監控(定時上下架)：
  
  當秒殺活動開始時推送該文件。
  
  當秒殺活動結束時推送文件，標示結束標誌，修改樣式。
  
  以下圖。

  淺談秒殺系統架構設計-1

• 如何只容許，第一個提交的單進入訂單系統。

  因爲秒殺到商品的用戶只有一個，所以須要在提交訂單時，進行下單前置檢查。
  
  若是已經有訂單提交成功，表示活動結束，進入秒殺結束頁面。
  
  事實上，訂單數只能有一個，爲了減輕下單頁面服務器的負載壓力，能夠控制進入下單頁面的入口。
  
  只有少數用戶能進入下單頁面，其餘用戶直接進入秒殺結束頁面。
  
  （前置檢查邏輯）檢查本機已處理的下單請求數目：
  
    若是超過10條，直接返回已結束頁面給用戶。
  
    若是未超過10條，則用戶可進入填寫訂單及確認頁面。
  
  （前置檢查邏輯）檢查全局已提交訂單數目：
  
    已超過秒殺商品總數，返回秒殺結束頁面。
  
    未超過秒殺商品總數，提交到子訂單系統。
  
    以下圖。

  淺談秒殺系統架構設計-2

• 減庫存的操做

  拍下減庫存(用戶體驗好)

  付款減庫存

  下訂單儘量簡單，購買數據爲1且不可編輯，送貨地址和付款方式爲空或用戶默認，容許訂單提交後修改。

文章借鑑書籍《大型網站技術架構》。

推薦閱讀

• 系統的講解 - SSO 單點登陸
• 系統的講解 - PHP WEB 安全防護
• 系統的講解 - PHP 緩存技術
• 系統的講解 - PHP 接口簽名驗證
• 系統的講解 - PHP 浮點數高精度運算

---