秒殺系統架構設計

秒殺活動的技術挑戰

1. 對現有網站業務形成衝擊

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

2. 高併發下的應用、數據庫負載

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

3. 忽然增長的網絡及服務器帶寬

假設商品頁面大小200K（主要是商品圖片大小），那麼須要的網絡和服務器帶寬是2G（200K×10000），這些網絡帶寬是由於秒殺活動新增的，超過網站平時使用的帶寬。

4. 直接下單

秒殺的遊戲規則是到了秒殺時間才能開始對商品下單購買，在此時間點以前，只能瀏覽商品信息，不能下單。而下單頁面也只是一個普通的URL，若是獲得這個URL，不用等到秒殺開始就能夠下單了。

 

秒殺系統的應對策略

1. 秒殺系統獨立部署

爲了不由於秒殺活動的高併發訪問而拖垮整個網站，使整個網站沒必要面對蜂擁而來的用戶訪問，可將秒殺系統獨立部署；若是須要，還可使用獨立的域名，使其與網站徹底隔離，即便秒殺系統崩潰了，也不會對網站形成任何影響。

2. 秒殺商品頁面靜態化

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

3. 租借秒殺活動網絡帶寬

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

4. 動態生成隨機下單頁面URL

爲了不用戶直接訪問下單頁面URL，須要將該URL動態化，即便秒殺系統的開發者也沒法在秒殺開始前訪問下單頁面的URL。辦法是在下單頁面URL加入由服務器端生成的隨機數做爲參數，在秒殺開始的時候才能獲得。

 

秒殺系統架構設計

秒殺系統爲秒殺而設計，不一樣於通常的網購行爲，參與秒殺活動的用戶更關心的是如何能快速刷新商品頁面，在秒殺開始的時候搶先進入下單頁面，而不是商品詳情等用戶體驗細節，所以秒殺系統的頁面設計應儘量簡單。

商品頁面中的購買按鈕只有在秒殺活動開始的時候才變亮，在此以前及秒殺商品賣出後，該按鈕都是灰色的，不能夠點擊。

下單表單也儘量簡單，購買數量只能是一個且不能夠修改，送貨地址和付款方式都使用用戶默認設置，沒有默認也能夠不填，容許等訂單提交後修改；只有第一個提交的訂單發送給網站的訂單子系統，其他用戶提交訂單後只能看到秒殺結束頁面。

 

除了上面提到的秒殺系統的技術挑戰及應對策略，還有一些其餘問題須要處理。

1. 如何控制秒殺商品頁面購買按鈕的點亮

購買按鈕只有在秒殺開始的時候才能點亮，在此以前是灰色的。若是該頁面是動態生成的，固然能夠在服務器端構造響應頁面輸出，控制該按鈕是灰色還 是點亮，可是爲了減輕服務器端負載壓力，更好地利用CDN、反向代理等性能優化手段，該頁面被設計爲靜態頁面，緩存在CDN、反向代理服務器上，甚至用戶 瀏覽器上。秒殺開始時，用戶刷新頁面，請求根本不會到達應用服務器。

解決辦法是使用JavaScript腳本控制，在秒殺商品靜態頁面中加入一個JavaScript文件引用，該JavaScript文件中包含 秒殺開始標誌爲否；當秒殺開始的時候生成一個新的JavaScript文件（文件名保持不變，只是內容不同），更新秒殺開始標誌爲是，加入下單頁面的 URL及隨機數參數（這個隨機數只會產生一個，即全部人看到的URL都是同一個，服務器端能夠用redis這種分佈式緩存服務器來保存隨機數），並被用戶 瀏覽器加載，控制秒殺商品頁面的展現。這個JavaScript文件的加載能夠加上隨機版本號（例如xx.js?v=32353823），這樣就不會被瀏 覽器、CDN和反向代理服務器緩存。

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

 

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

因爲最終可以成功秒殺到商品的用戶只有一個，所以須要在用戶提交訂單時，檢查是否已經有訂單提交。若是已經有訂單提交成功，則須要更新 JavaScript文件，更新秒殺開始標誌爲否，購買按鈕變灰。事實上，因爲最終可以成功提交訂單的用戶只有一個，爲了減輕下單頁面服務器的負載壓力， 能夠控制進入下單頁面的入口，只有少數用戶能進入下單頁面，其餘用戶直接進入秒殺結束頁面。假設下單服務器集羣有10臺服務器，每臺服務器只接受最多10 個下單請求。在尚未人提交訂單成功以前，若是一臺服務器已經有十單了，而有的一單都沒處理，可能出現的用戶體驗不佳的場景是用戶第一次點擊購買按鈕進入 已結束頁面，再刷新一下頁面，有可能被一單都沒有處理的服務器處理，進入了填寫訂單的頁面，能夠考慮經過cookie的方式來應對，符合一致性原則。固然 能夠採用最少鏈接的負載均衡算法，出現上述狀況的機率大大下降。

 

小結

秒殺是對網站架構的極大考驗，在難以預計和控制的高併發訪問的衝擊下，稍有不慎，系統就會被用戶秒殺，致使整個系統宕機，活動失敗，構成重大事故。所以在 遵循秒殺活動遊戲規則的基礎上，爲了保證系統的安全，保持適度的公平公正便可。即便系統出了故障，也不該該給用戶顯示出錯頁面，而是顯示秒殺活動結束頁 面，避免沒必要要的困擾。

 

摘自《大型網站技術架構：核心原理與案例分析》 李智慧  豆瓣讀書