秒殺是電子商務網站常見的一種營銷手段。
原則
- 不要整個系統(tǒng)宕機。
- 即使系統(tǒng)故障，也不要將錯誤數(shù)據(jù)展示出來。
- 盡量保持公平公正。
實現(xiàn)效果
- 秒殺開始前，搶購按鈕為活動未開始。
- 秒殺開始時，搶購按鈕可以點擊下單。
- 秒殺結束后，按鈕按鈕變成秒殺已結束。
技術攻關
-
短時間內的大訪問量對現(xiàn)有網站業(yè)務造成的沖擊。
秒殺是一個網站營銷的一個附加活動，時間短，并發(fā)量大。
如果和網站原有應用部署在一起，必然會對現(xiàn)有業(yè)務造成沖擊，稍有不慎可能導致整個網站癱瘓。
-
高并發(fā)下對服務器數(shù)據(jù)庫造成的極大負載壓力。
用戶秒殺開始前，通過不斷刷新瀏覽器來保證不會錯過秒殺活動。
頻繁的訪問程序、數(shù)據(jù)庫會對應用服務器和數(shù)據(jù)庫服務器造成負載壓力。
-
網絡帶寬的問題比超過平時好多倍。
如果秒殺頁面的大小為200K，如果最大并發(fā)數(shù)為10000次，那么需要的網絡和服務器帶寬是2G（200K×10000）。
這些網絡帶寬是因為秒殺活動新增的，超過網站平時使用的帶寬。
-
避免直接下單。
秒殺的游戲規(guī)則是到了秒殺才能開始對商品下單購買，在此時間點之前，只能瀏覽信息不可下單。
而下單頁面也是一個普通的URL，如果得到這個URL，不用等到秒殺開始就可以下單了。
應對策略
-
秒殺系統(tǒng)獨立部署
為了避免短時間內的大訪問量對現(xiàn)有網站業(yè)務造成的沖擊，可以將秒殺系統(tǒng)獨立部署。
如果需要還可以使用獨立域名，使其與網站完全隔離。
即使秒殺系統(tǒng)崩潰了，也不會對網站造成影響。
-
秒殺商品頁面靜態(tài)化
將商品描述、參數(shù)、詳情，全部寫到一個靜態(tài)頁面，不用進行程序的邏輯處理，不需訪問數(shù)據(jù)庫。
不用部署動態(tài)的服務器和數(shù)據(jù)庫服務器。
-
租借秒殺活動的網絡帶寬
因為秒殺新增的網絡帶寬，必須和運營商重新購買或租借帶寬。
為了減輕服務器的壓力，需要將秒殺商品頁面緩存在CDN,同樣CDN服務器也需要臨時租借帶寬。
-
動態(tài)生成隨機下單頁面的URL
為了避免用戶直接訪問下單URL,需要將URL動態(tài)化，用隨機數(shù)作為參數(shù)，只能秒殺開始的時候才生成。
架構設計
-
如何控制秒殺商品頁面搶購按鈕的可用/禁用。
購買按鈕只有在秒殺開始的時候才能點亮，在此之前是灰色的，顯示活動未開始。
如果頁面是動態(tài)生成的，每次刷新都要請求服務器，那么勢必造成服務端的負載壓力。
如果頁面是靜態(tài)頁面的話，可以將頁面緩存在CDN，反向代理服務器上，甚至用戶瀏覽器上。
但是這樣，秒殺開始時，用戶刷新頁面，根本請求不到應用服務器。
解決方案：
使用JS腳本控制，在頁面中引用一個JS文件(文件極小)，但是該文件不要被緩存。
該JS的作用是，包含秒殺開始標志，修改樣式，生成下單頁面的URL及隨機參數(shù)。
該JS文件不被緩存的做法：xxx.js?v=隨機數(shù)。
會有一臺服務器進行監(jiān)控(定時上下架)：
當秒殺活動開始時推送該文件。
當秒殺活動結束時推送文件，標示結束標志，修改樣式。
如下圖。
-
如何只允許，第一個提交的單進入訂單系統(tǒng)。
由于秒殺到商品的用戶只有一個，因此需要在提交訂單時，進行下單前置檢查。
如果已經有訂單提交成功，表示活動結束，進入秒殺結束頁面。
事實上，訂單數(shù)只能有一個，為了減輕下單頁面服務器的負載壓力，可以控制進入下單頁面的入口。
只有少數(shù)用戶能進入下單頁面，其他用戶直接進入秒殺結束頁面。
（前置檢查邏輯）檢查本機已處理的下單請求數(shù)目：
如果超過10條，直接返回已結束頁面給用戶。
如果未超過10條，則用戶可進入填寫訂單及確認頁面。
（前置檢查邏輯）檢查全局已提交訂單數(shù)目：
已超過秒殺商品總數(shù)，返回秒殺結束頁面。
未超過秒殺商品總數(shù)，提交到子訂單系統(tǒng)。
如下圖。
-
減庫存的操作
拍下減庫存(用戶體驗好)
付款減庫存
下訂單盡可能簡單，購買數(shù)據(jù)為1且不可編輯，送貨地址和付款方式為空或用戶默認，允許訂單提交后修改。
文章借鑒書籍《大型網站技術架構》。
Thanks ~
