秒殺系統架構如何設計之我見

秒殺背景

電商中爲了吸引顧客、彙集人氣，常常會策劃一些秒殺活動。活動中售賣的商品，要麼價格遠低於市場價格，要麼比較稀缺（如一些新發布的商品）。這些商品電商通常都會限量、限時銷售。無疑這些商品對消費者的誘惑力是巨大的，消費者蜂擁而來，每每幾秒鐘就能夠將商品搶購一空。而對於電商系統來講可能更多的是考驗。

秒殺痛點

首先，秒殺的場景決定了秒殺是一場速度的比拼，也就是俗話說的「手快有、手慢無」。你們都爭着在活動開始後，第一時間將商品搶到，完成下單。所以秒殺活動開始的一瞬間會有大量的流量涌入，幾倍、甚至於十幾倍的流量對系統的衝擊不可謂不大。若是系統沒有足夠的capacity或應對措施，極可能就被瞬時高流量給壓垮了。

其次，突如其來的高流量，給系統各個模塊都來了一連串的壓力，系統可能會所以變慢，並且可能會彼此影響，影響可用性。好比：數據庫更新同一個商品庫存，需對同一行記錄加鎖，隨着併發的壓力逐漸增大，數據庫更新的性能是逐漸降低的。從而引發提供庫存service的應用服務性能降低，連鎖的影響到下單service的性能，最終反饋到消費者的可能就是整個網站購物流程性能差、響應慢。而面對響應慢的系統，不少消費者可能採起反覆刷新，屢次嘗試，這無疑又增大了對系統的壓力。

還有，上述種種給消費者帶來的每每是體驗上的痛苦。如：網站響應慢，點擊搶購按鈕沒反應。好不容易能夠操做了，卻發現秒殺活動已經結束，消費者的參與感比較差。長此以往，可能就對此類活動失去了興趣。

設計理念

分層限流：將壓力盡可能集中在前端，減小數據庫、服務器的壓力
異步處理：異步處理防止阻塞。
可用性：高可用雙活。
用戶體驗：隱藏購買地址。
分離：主站分離。

技術攻關

短期內的大訪問量對現有網站業務形成的衝擊。

秒殺是一個網站營銷的一個附加活動，時間短，併發量大。

若是和網站原有應用部署在一塊兒，必然會對現有業務形成衝擊，稍有不慎可能致使整個網站癱瘓。

高併發下對服務器數據庫形成的極大負載壓力。

用戶秒殺開始前，經過不斷刷新瀏覽器來保證不會錯過秒殺活動。

頻繁的訪問程序、數據庫會對應用服務器和數據庫服務器形成負載壓力。

網絡帶寬的問題比超過平時好多倍。

若是秒殺頁面的大小爲200K，若是最大併發數爲10000次，那麼須要的網絡和服務器帶寬是2G（200K×10000）。

這些網絡帶寬是由於秒殺活動新增的，超過網站平時使用的帶寬。

避免直接下單。

秒殺的遊戲規則是到了秒殺才能開始對商品下單購買，在此時間點以前，只能瀏覽信息不可下單。

而下單頁面也是一個普通的URL，若是獲得這個URL，不用等到秒殺開始就能夠下單了。

應對策略

秒殺系統獨立部署

爲了不短期內的大訪問量對現有網站業務形成的衝擊，能夠將秒殺系統獨立部署。

若是須要還可使用獨立域名，使其與網站徹底隔離。

即便秒殺系統崩潰了，也不會對網站形成影響。

秒殺商品頁面靜態化

將商品描述、參數、詳情，所有寫到一個靜態頁面，不用進行程序的邏輯處理，不需訪問數據庫。

不用部署動態的服務器和數據庫服務器。

租借秒殺活動的網絡帶寬

由於秒殺新增的網絡帶寬，必須和運營商從新購買或租借帶寬。

爲了減輕服務器的壓力，須要將秒殺商品頁面緩存在CDN,一樣CDN服務器也須要臨時租借帶寬。

動態生成隨機下單頁面的URL

爲了不用戶直接訪問下單URL,須要將URL動態化，用隨機數做爲參數，只能秒殺開始的時候才生成。

架構設計

如何控制秒殺商品頁面搶購按鈕的可用/禁用。

購買按鈕只有在秒殺開始的時候才能點亮，在此以前是灰色的，顯示活動未開始。

若是頁面是動態生成的，每次刷新都要請求服務器，那麼勢必形成服務端的負載壓力。

若是頁面是靜態頁面的話，能夠將頁面緩存在CDN，反向代理服務器上，甚至用戶瀏覽器上。

可是這樣，秒殺開始時，用戶刷新頁面，根本請求不到應用服務器。

解決方案：

使用JS腳本控制，在頁面中引用一個JS文件(文件極小)，可是該文件不要被緩存。

該JS的做用是，包含秒殺開始標誌，修改樣式，生成下單頁面的URL及隨機參數。

該JS文件不被緩存的作法：xxx.js?v=隨機數。

會有一臺服務器進行監控(定時上下架)：

當秒殺活動開始時推送該文件。

當秒殺活動結束時推送文件，標示結束標誌，修改樣式。

詳情：2018-01-27 20:00 實戰構建PHP千萬級PV秒殺系統 講堂