這次618京東實現(xiàn)下單金額2692億元，你貢獻了多少份額呢？

從5月25日-5月31日進入預熱階段，6月1日-6月15日進入專場階段，6月16日-6月18日進入高潮階段，6月18日-6月20日進入返場階段，每個階段都有每個階段的玩法，優(yōu)惠券、紅包、滿減、限時秒殺，讓你心甘情愿的掏出錢包還樂樂呵呵。

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

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

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

我們需要把秒殺系統(tǒng)當成一套獨立的電子商務系統(tǒng)進行設計，設計內(nèi)容包含業(yè)務系統(tǒng)、網(wǎng)絡帶寬、運維部署等部分。

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

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

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

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

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

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

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

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

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

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

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

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

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