秒殺是電子商務網站常見的一種營銷手段。數據庫
原則瀏覽器
不要整個系統宕機。緩存
即便系統故障，也不要將錯誤數據展現出來。服務器
儘可能保持公平公正。微信
實現效果網絡
秒殺開始前，搶購按鈕爲活動未開始。架構
秒殺開始時，搶購按鈕能夠點擊下單。併發
秒殺結束後，按鈕按鈕變成秒殺已結束。高併發
技術攻關網站
短期內的大訪問量對現有網站業務形成的衝擊。
秒殺是一個網站營銷的一個附加活動，時間短，併發量大。
若是和網站原有應用部署在一塊兒，必然會對現有業務形成衝擊，稍有不慎可能致使整個網站癱瘓。
高併發下對服務器數據庫形成的極大負載壓力。
用戶秒殺開始前，經過不斷刷新瀏覽器來保證不會錯過秒殺活動。
頻繁的訪問程序、數據庫會對應用服務器和數據庫服務器形成負載壓力。
網絡帶寬的問題比超過平時好多倍。
若是秒殺頁面的大小爲200K，若是最大併發數爲10000次，那麼須要的網絡和服務器帶寬是2G（200K×10000）。
這些網絡帶寬是由於秒殺活動新增的，超過網站平時使用的帶寬。
避免直接下單。
秒殺的遊戲規則是到了秒殺才能開始對商品下單購買，在此時間點以前，只能瀏覽信息不可下單。
而下單頁面也是一個普通的URL，若是獲得這個URL，不用等到秒殺開始就能夠下單了。
應對策略
秒殺系統獨立部署
爲了不短期內的大訪問量對現有網站業務形成的衝擊，能夠將秒殺系統獨立部署。
若是須要還可使用獨立域名，使其與網站徹底隔離。
即便秒殺系統崩潰了，也不會對網站形成影響。
秒殺商品頁面靜態化
將商品描述、參數、詳情，所有寫到一個靜態頁面，不用進行程序的邏輯處理，不需訪問數據庫。
不用部署動態的服務器和數據庫服務器。
租借秒殺活動的網絡帶寬
由於秒殺新增的網絡帶寬，必須和運營商從新購買或租借帶寬。
爲了減輕服務器的壓力，須要將秒殺商品頁面緩存在CDN,一樣CDN服務器也須要臨時租借帶寬。
動態生成隨機下單頁面的URL
爲了不用戶直接訪問下單URL,須要將URL動態化，用隨機數做爲參數，只能秒殺開始的時候才生成。
架構設計
如何控制秒殺商品頁面搶購按鈕的可用/禁用。
購買按鈕只有在秒殺開始的時候才能點亮，在此以前是灰色的，顯示活動未開始。
若是頁面是動態生成的，每次刷新都要請求服務器，那麼勢必形成服務端的負載壓力。
若是頁面是靜態頁面的話，能夠將頁面緩存在CDN，反向代理服務器上，甚至用戶瀏覽器上。
可是這樣，秒殺開始時，用戶刷新頁面，根本請求不到應用服務器。
解決方案：
使用JS腳本控制，在頁面中引用一個JS文件(文件極小)，可是該文件不要被緩存。
該JS的做用是，包含秒殺開始標誌，修改樣式，生成下單頁面的URL及隨機參數。
該JS文件不被緩存的作法：xxx.js?v=隨機數。
會有一臺服務器進行監控(定時上下架)：
當秒殺活動開始時推送該文件。
當秒殺活動結束時推送文件，標示結束標誌，修改樣式。
以下圖。
如何只容許，第一個提交的單進入訂單系統。
因爲秒殺到商品的用戶只有一個，所以須要在提交訂單時，進行下單前置檢查。
若是已經有訂單提交成功，表示活動結束，進入秒殺結束頁面。
事實上，訂單數只能有一個，爲了減輕下單頁面服務器的負載壓力，能夠控制進入下單頁面的入口。
只有少數用戶能進入下單頁面，其餘用戶直接進入秒殺結束頁面。
（前置檢查邏輯）檢查本機已處理的下單請求數目：
若是超過10條，直接返回已結束頁面給用戶。
若是未超過10條，則用戶可進入填寫訂單及確認頁面。
（前置檢查邏輯）檢查全局已提交訂單數目：
已超過秒殺商品總數，返回秒殺結束頁面。
未超過秒殺商品總數，提交到子訂單系統。
以下圖。
減庫存的操做
拍下減庫存(用戶體驗好)
付款減庫存
下訂單儘量簡單，購買數據爲1且不可編輯，送貨地址和付款方式爲空或用戶默認，容許訂單提交後修改。
文章借鑑於書籍《大型網站技術架構》。
Thanks ~
本文分享自微信公衆號 - 新亮筆記（XinLiangTalk）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。