網購秒殺系統架構設計案例分析——《大型網站技術架構》筆記

1、核心思想：

網站秒殺時的併發比正常運營時多的多，因此網站的秒殺業務不能使用正常的網站業務流程，也不能和正常的網站交易業務共用服務器（不然形成巨大浪費），必須設計部署專門的秒殺系統，進行專門應對

 

2、技術挑戰：

1.對現有網站業務形成衝擊：秒殺活動只是網站營銷的一個附加活動，具備時間短，高併發的特色，若是和網站原有應用部署在一塊兒，必然會對現有業務形成衝擊，稍有不慎可能致使整個網站癱瘓

2.高併發下的應用、數據庫負載：用戶在秒殺開始前，經過不停刷新頁面以保證不錯過秒殺，這些請求按照通常的網站應用架構，訪問應用服務器、鏈接數據庫，會對應用服務器和數據庫服務器形成極大的負載壓力

3.忽然增長的網絡及服務器帶寬：假設商品頁面大小200K，最大併發請求數是10000，則須要網絡和服務器帶寬是2G（200K*10000），這些網絡帶寬是由於秒殺活動新增的，超過網站平時使用的帶寬

4.直接下單：下單頁面也是一個普通URL，要防止用戶在秒殺開始前訪問這個URL（下單）

 

3、應對策略：

1.秒殺系統獨立部署：避免高併發拖垮整個網站，還可以使用獨立域名使其與網站徹底隔離，即便秒殺系統崩潰也不對網站形成任何影響

2.秒殺商品頁面靜態化：秒殺商品頁面不使用網站本來的商品詳情頁面，頁面內容靜態化，將商品描述、商品參數、成交記錄和用戶評價所有寫入一個靜態頁面，用戶請求不須要通過應用服務器的業務邏輯處理，也不需訪問數據庫。因此秒殺商品服務不須要部署動態的Web服務器和數據庫服務器

3.租借秒殺活動網絡帶寬：秒殺新增的網絡帶寬，必須和運營商從新購買或租借。爲減輕網站服務器壓力，須要將秒殺商品頁面緩存在CDN，一樣須要和CDN服務商臨時租借新增的出口帶寬

4.動態生成隨機下單頁面URL：避免用戶直接訪問下單頁面URL，在下單頁面URL加入由服務器端生成的隨機數做爲參數，在秒殺開始的時候才能獲得，即便秒殺系統的開發者也沒法在秒殺開始前訪問下單頁面的URL。

 

4、秒殺系統架構設計：

1.頁面設計儘量簡單（用戶更關心如何快速刷新進入下單頁面，而不是商品詳情等用戶體驗細節）：

①購買按鈕在秒殺活動開始時才變亮，在此以前都置灰，不可點 ②下單表單也儘量簡單：1️⃣購買數量只能是一個且不可更改 2️⃣送貨地址和付款方式都使用用戶默認設置，沒有默認也可不填，容許等訂單提交後修改（商品頁面是靜態的，下單頁面仍是動態的） 3️⃣只有第一個提交的訂單發送給網站的訂單子系統，其他用戶提交訂單後只能看到秒殺結束頁面

具體實現：

①購買按鈕如何控制：因爲商品頁面靜態化（可能緩存在CDN、反向代理甚至用戶瀏覽器，秒殺開始時用戶刷新頁面請求不會到達應用服務器，因此按鈕不能動態生成），

解決辦法是用JS控制，在秒殺頁面加入一個JS文件引用，該JS文件加入 秒殺是否開始標識 和 下單頁面的URL的隨機參數，當秒殺開始時生成新的一個JS文件並被用戶瀏覽器加載，控制秒殺商品頁面的展現。這個JS文件使用隨機版本號，而且不被瀏覽器、CDN和反向代理服務器緩存。以下圖所示：

 這個JS文件很是小，即便每次瀏覽器刷新訪問JS文件服務器也不會對服務器集羣和網絡帶寬形成太大壓力。

②如何只容許第一個提交的訂單被髮送到訂單子系統：

1️⃣在用戶提交訂單時，檢查是否已經有訂單提交 2️⃣爲減輕服務器負載壓力，能夠控制進入下單頁面的入口，只有少數用戶能進入下單頁面，其餘用戶直接進入秒殺結束頁面（下圖爲假設下單服務器集羣有10臺服務器，每臺服務器只接受最多10個下單請求）

 

秒殺系統的總體架構以下：

小結：

在遵循秒殺活動遊戲規則的基礎上，保持適度的公平公正便可。即便系統出了故障，也不該該給用戶顯示出錯界面，而是顯示秒殺活動結束頁面，避免沒必要要的困擾。

後續還有一篇關於性能優化設計的筆記，幾乎也均可以用於秒殺系統的優化。