網購秒殺系統架構設計

本文是「大型網站技術架構 - 核心原理與案例分析」 第 12 章的學習筆記，感興趣的朋友能夠去購買

目錄：

• 秒殺活動的技術挑戰
• 秒殺活動的應對策略
• 秒殺系統架構設計

1、秒殺活動的技術挑戰

場景： 某網站秒殺活動推出 1 件商品，預計吸引 10000 人蔘加，及最大併發請求數 10000

1.1 對現有業務的衝擊

秒殺活動做爲網站業務的附加活動，具備持續時間短、併發訪問量大的特色。
與主業務部署相同服務器，會對現有業務形成衝擊。

1.2 高併發下的應用、數據庫負載

參與秒殺活動的用戶，會在秒殺開始前，不斷刷新瀏覽器。
若是按照正常訪問應用服務器、鏈接數據庫將對它們形成極大負載壓力。

1.3 突增的網路及服務器帶寬

假定秒殺活動頁面大小 200k ，則在活動期間須要的網絡和服務器帶寬爲 2G(200k * 10000)。這超過網站平時使用的帶寬。

1.4 直接下單

秒殺活動僅能在開始活動後下單，開始前僅能瀏覽商品，若是用戶獲取到直接下單頁面 URL 則能夠直接下單。

2、秒殺活動應對策略

2.1 秒殺系統獨立部署

a. 秒殺活動獨立部署應用服務器
b. 能夠獨立部署域名

2.2 秒殺頁面靜態化

秒殺活動不使用原商品頁面，而是將商品描述、商品參數、成交記錄、用戶評論等所有寫入靜態頁面，這樣用戶訪問時無需通過應用服務器及鏈接數據庫。

2.3 租借秒殺帶寬

爲減輕服務器壓力
a. 將秒殺活動頁面緩存在 CDN
b. 從 CDN 服務商臨時租借出口帶寬

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

3、 秒殺系統架構設計

3.1 「購買」按鈕僅在秒殺開始後可用

活動開始前及結束後「購買」按鈕置灰

3.2 簡化下單頁面

a. 購買數量不可修改，僅能購買 1 件
b. 收貨地址及付款方式僅支持用戶默認設置
c. 無默認設置的收貨地址用戶，支持下單後補填

3.3 挑戰

• 如何控制秒殺活動的「購買」按鈕點亮？

緣由： 因爲頁面採用 CDN、反向代理及頁面靜態化策略。秒殺開始時用戶刷新頁面，請求沒法到達應用服務器

解決： 使用 JavaScript 腳本控制
原理是在秒殺商品靜態頁面加入 JavaScript 文件引用，該 js 加入秒殺開始標誌及下單頁面 URL 的隨機參數。
秒殺開始時生成新的 JavaScript爲不見並被用戶瀏覽器加載，打到控制秒殺頁面展現的目的。

• 如何只容許第一個提交的訂單被髮送到訂單子系統

緣由： 參與活動用戶多，秒殺商品數量有限，如何去報用戶提交訂單式檢查是否已有訂單提交

解決： 控制進入下單頁面入口，僅容許少數用戶進入下單頁面，其它用戶直接進入秒殺結束頁面