如何實現「秒殺」系統

昨晚和一公司工做幾年的同事閒扯了一些程序人生和技術問題。感受本身目前的經驗仍是太少太少了，看的書也不是太多，慚愧啊。

就好比同事問了我一個如何作一個咱們很常見的「秒殺」系統，我當時一拍腦門直接回答說加個排它鎖不就好了麼，可是晚上回到家裏google了一番以後，深深的感到臉紅啊。一個看似簡單的「秒殺」系統，裏面涉及到的東西也着實很多，而不只僅是一個簡單的加鎖就好了的。我大體整理了一下我想到的和google到的須要注意的地方，固然有不少的不足，同時也但願大神們可以指點一點：

1） 對現有網站業務的衝擊

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

2） 高併發狀況以及數據庫的負載

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

3） 忽然增長的網絡和服務器帶寬

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

4） 直接下單

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

5） 防止機器秒殺

防止網上的一些「秒殺器」

針對上面的5個問題，對應的策略以下：

1）  秒殺系統獨立部署

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

2）  秒殺商品頁面靜態化

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

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

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

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

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

5）  防止「秒殺器」感受很難，

由於彷佛老是有辦法能夠跳過設置的「障礙」。真正作到防止，僅靠webserver怕是很難防範，通常的作法都是增長一些人爲的「障礙」，好比：

註冊時有必定的門檻，像皮皮書屋同樣，經過輸入程序執行結果做爲驗證 –à以前批量手工註冊

參加秒殺的積分或者等級策略 -à 掛太陽，就如同你當你爲了升級QQ等級的時候一直掛着QQ同樣。

驗證碼，阻止自動化操做 -à 能夠圖像識別

ip阻止 –à 可是ip能夠僞造,能夠代理