秒殺搶購背景

秒殺搶購架構設計和模塊劃分

秒殺搶購接入層實現

電商網站的常規架構

常規狀態下電商網站的架構體系如下：

秒殺搶購業務分析

正常電子商務流程：

查詢商品 》 創建訂單 》 扣減庫存 》更新訂單 》付款 》賣家發貨 》確認收貨

秒殺業務的特性：

（1）低廉價格；（2）大幅推廣；（3）瞬時售空；（4）一般是定時上架；（5）時間短、瞬時并發量高；

?假設某網站秒殺活動只推出一件商品，預計會吸引1萬人參加活動，也就說最大并發請求數是10000，秒殺系統需要面對的技術挑戰有：

1.對現有網站業務造成沖擊

秒殺活動只是網站營銷的一個附加活動，這個活動具有時間短，并發訪問量大的特點，如果和網站原有應用部署在一起，必然會對現有業務造成沖擊，稍有不慎可能導致整個網站癱瘓。

解決方案：將秒殺系統獨立部署，甚至使用獨立域名，使其與網站完全隔離。

2. 高并發下的應用、數據庫負載

用戶在秒殺開始前，通過不停刷新瀏覽器頁面以保證不會錯過秒殺，這些請求如果按照一般的網站應用架構，訪問應用服務器、連接數據庫，會對應用服務器和數據庫服務器造成負載壓力。

解決方案：重新設計秒殺商品頁面，不使用網站原來的商品詳細頁面，頁面內容靜態化，用戶請求不需要經過應用服務。

3. 突然增加的網絡及服務器帶寬

假設商品頁面大小200K（主要是商品圖片大小），那么需要的網絡和服務器帶寬是2G（200K×10000），這些網絡帶寬是因為秒殺活動新增的，超過網站平時使用的帶寬。

解決方案：因為秒殺新增的網絡帶寬，必須和運營商重新購買或者租借。為了減輕網站服務器的壓力，需要將秒殺商品頁面緩存在CDN，同樣需要和CDN服務商臨時租借新增的出口帶寬。

4. 直接下單

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

解決方案：為了避免用戶直接訪問下單頁面URL，需要將改URL動態化，即使秒殺系統的開發者也無法在秒殺開始前訪問下單頁面的URL。辦法是在下單頁面URL加入由服務器端生成的隨機數作為參數，在秒殺開始的時候才能得到。

5. 如何控制秒殺商品頁面購買按鈕的點亮

購買按鈕只有在秒殺開始的時候才能點亮，在此之前是灰色的。如果該頁面是動態生成的，當然可以在服務器端構造響應頁面輸出，控制該按鈕是灰色還 是點亮，但是為了減輕服務器端負載壓力，更好地利用CDN、反向代理等性能優化手段，該頁面被設計為靜態頁面，緩存在CDN、反向代理服務器上，甚至用戶瀏覽器上。秒殺開始時，用戶刷新頁面，請求根本不會到達應用服務器。

解決方案：使用JavaScript腳本控制，在秒殺商品靜態頁面中加入一個JavaScript文件引用，該JavaScript文件中包含 秒殺開始標志為否；當秒殺開始的時候生成一個新的JavaScript文件（文件名保持不變，只是內容不一樣），更新秒殺開始標志為是，加入下單頁面的URL及隨機數參數（這個隨機數只會產生一個，即所有人看到的URL都是同一個，服務器端可以用redis這種分布式緩存服務器來保存隨機數），并被用戶瀏覽器加載，控制秒殺商品頁面的展示。這個JavaScript文件的加載可以加上隨機版本號（例如xx.js?v=32353823），這樣就不會被瀏覽器、CDN和反向代理服務器緩存。

這個JavaScript文件非常小，即使每次瀏覽器刷新都訪問JavaScript文件服務器也不會對服務器集群和網絡帶寬造成太大壓力。

…………

更多內容參考：

秒殺系統架構分析與實戰 - 陶邦仁的個人空間 - OSCHINA - 中文開源技術交流社區

秒殺搶購功能的演進

秒殺搶購的發展經歷如下：

1.0版，沒有獨立的秒殺系統，代碼高度耦合，由于MySQL的性能瓶頸大流量涌入會導致平臺整體崩潰。

2.0版，使用Redis搭建獨立的秒殺系統，實現系統解耦進行限流和過載保護，平臺不會崩潰，但是秒殺系統可能會崩潰。

3.0版，對秒殺系統內部進行拆分，對秒殺系統單獨做限流和過載保護等。

秒殺搶購架構

秒殺搶購架構圖如下，其內部還有一個日志收集模塊用于數據挖掘篩選黑名單等。

代碼實現

接入層

邏輯層

總結

以上是生活随笔為你收集整理的go 商品秒杀系统架构设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。