如今的購物節“套路”有很多，從預熱階段、專場階段，到高潮階段、返場階段，每個階段都有每個階段的玩法，優惠券、紅包、滿減、限時秒殺，讓你心甘情愿的掏出錢包還樂樂呵呵。

而這其中最具吸引力的便是“限時秒殺”了，因為參加限時秒殺的商品，價格非常的便宜，在上架之前商家和平臺都會進行大量的宣傳，并且只在某個時間點上架，由于上述三個特征有大量的用戶定點來參加限時秒殺活動，這導致瞬間系統并發量會增加。

還記得2013年的小米秒殺活動嗎？三款小米手機各11萬臺開賣，3分鐘就售光，每秒接近60萬個請求，而支撐如此瞬間爆發海量請求的系統便是秒殺系統了，而今天我們就給大家揭秘大促背后的秒殺系統如何進行設計～

商品秒殺本質上也是一種運營活動，通過低廉的價格吸引大量用戶，打造品牌，為店鋪引流，所以秒殺商品的整個流程自然也包括商品信息展示、用戶查詢商品、用戶購買商品創建訂單、系統扣減庫存、系統更新訂單信息、用戶付款、商家發貨了。

我們需要把秒殺系統當成一套獨立的電子商務系統進行設計，設計內容包含業務系統、網絡帶寬、運維部署等部分。

秒殺系統的業務規則是到了秒殺時間才能對商品進行下單購買，在該時間點之前只能瀏覽商品信息，不能下單。而因為秒殺商品，比如小米手機、iPhone、空調、春運火車票等商品都屬于很難搶購，所以必定有黃牛、搶票軟件等不斷的去發起請求，甚至會有高手通過寫自動化腳本獲取商品。

所以在秒殺系統的前端設計和后端設計都需要把這些點考慮進來。

從前端設計來說，秒殺商品購買的按鈕只有等到秒殺時才可以點擊，在秒殺到來的那一刻之前，必定有用戶不斷的刷新頁面，這一幕想必小伙伴們一定很熟悉吧，618、雙11、春運放票之前不斷的用手機、電腦刷新頁面。

每次刷新都會給服務器端帶來負載壓力，因此將該頁面設計成靜態頁面，緩存在CDN、用戶瀏覽器、反向代理服務器上。對于購買按鈕的點擊與否通過js腳本來動態控制。

從后端設計來說，秒殺活動一開始，必定涌來大量的請求，需要通過限流、消息隊列等手段保障服務可正常運行。

首先通過服務的集群部署，使用負載均衡工具（如Nginx）將用戶請求分發到不同的機器上，能一定程度緩解服務器壓力。

其次通過使用MQ消息中間件將用戶請求全放在隊列里，通過設置隊列的最大閾值（即商品的最大庫存數）可以保障用戶都能正常請求服務，消息隊列把商品系統和庫存系統分為了兩部分，使得下單、減庫存操作互相不強制依賴從而保障了用戶的使用體驗。

最后將成功進入消息隊列的請求封裝成事務提交給數據庫，由數據庫進行處理即可。

從網絡設計上來說，因為商品的html頁面包含了商品描述、商品圖片等信息，再加上css、js腳本等資源，大概有幾百K（我們假設600K），如果同時10000人參與一個商品的搶購，需要的網絡帶寬大約是6G（600K*10000），而這些帶寬的增加是因為秒殺活動帶來的，平時使用不了這么多，比較好的方式就是和運營商臨時租借。

從服務部署來說，因為秒殺活動時間短、高并發的特點，為了避免對整個網站造成沖擊、帶來癱瘓，一般采用獨立部署，使其與網站單獨隔離。

從參與者公平的角度來說，因為秒殺活動物美價廉量少，除了用戶自己在搶之外，還有大量的搶票軟件、黃牛在進行搶購，為了保障活動的公平性，我們可在瀏覽器和服務端進行設計。

在瀏覽器端，通過JS腳本限制用戶在N秒內只能提交一次請求，點擊了查詢或購買按鈕之后，不能再次點擊。在服務器端，對于同一個ID，限制訪問的頻率，N秒內到達后端的請求只返回同一頁面，同一個商品的查詢，N秒內到達的只返回同一個頁面。通過技術手段的限制，即使是高手也不能囤積大量的貨物。

以前，我們都是作為參與者參加商品的秒殺活動，在618、雙十一這樣的大促里貢獻訂單額，而現在，特別是在今天介紹了秒殺系統的設計后，我們更應該以技術人的角度去看全民狂歡節，每一次訂單額的上升背后都是技術上又一次突破啊。雙十一即將到來，我們且期待著此次的訂單額又是多少億的突破以及背后的又一次技術升級吧～