業務背景

業務基本場景

當前電商系統已經拆分為商品、訂單、會員三個子系統，但為了確保秒殺系統可以支撐瞬間高流量請求，且不影響到非秒殺商品的購物體驗，因此將秒殺系統作為一個新的獨立子系統。

約束和限制

• 使用者必須註冊並登入才能進行購物

• 秒殺活動限定只能透過 app 才能參加

• 秒殺商品僅提供 1000 個充電寶和 10 台 iphone 12，搶完不補。

• 非秒殺商品能正常進行瀏覽與購買

總體架構思路

假設日活躍人數為 100 萬個用戶，且約為總用戶數的 20%，則當前總用戶數約為 500 萬個用戶。

且目前已經拆分為三個子系統，以三個火槍手原則來分配人力的話，當前後端人員至少有 9 位，但因為需要增加一個新的子系統，所以後端人員總數應該至少增長到 12 位。

由於下一級為千萬級用戶，而當前用戶數約 500 萬名，團隊人數也不算很多，所以還是以百萬級別設計架構。

儲存架構設計

儲存性能估算

數據量

• 假設當前用戶數約為 500 萬個用戶，預留 1.5 倍作為未來增長的量，則用戶數據儲存量為:

• 500 萬 * 1.5 = 750 萬筆

• 商品數量在每個品類裡最多 20 個，目前已經做了 10 個品類，預留 2 倍作為未來增長的量，則商品總數為:

• 20 個商品 * 10 個品類 * 2 = 400 個

• 日活約 100 萬個用戶，其中假設有 20% 用戶會下一張訂單，且訂單數據需保留 3 年，則訂單總筆數約為:

• 100 萬 * 20% * 3 * 365 = 5475 萬筆

儲存架構設計

用戶相關數據

使用 MySQL 主備複製架構即可，因數據量估算如下:

• 750 萬用戶註冊信息

• 100 萬用戶登入請求

• 400 個商品

• 5475 萬筆訂單記錄

秒殺商品數據

秒殺商品一共會產生 1010 個序號，在活動開始前寫入，雖然初始寫入請求數不多，但因秒殺活動開始後，瞬間會有大量請求來拿序號 (要將狀態改成已使用)，如果使用 redis master/slave 模式，單點支撐不住，所以選擇用 redis cluster 模式。

計算架構設計

計算性能估算

假設數據

• 假設當前總用戶數約為 500 萬個用戶，但為秒殺活動會帶來新用戶。

• 假設秒殺活動帶來的新用戶數約為總用戶數的 10%，所以新用戶數量約為:

• 500 萬 * 10 % = 50 萬個用戶

• 非活躍用戶可能會因為秒殺活動而回來購物，假設有 20% 非活躍的用戶有興趣，則回歸用戶數約為:

• 500 萬 * 80%(非活躍) * 20% (非活躍且有興趣) = 80 萬個用戶

• 假設秒殺活動參與的人包含日活全部人數、回歸用戶、新用戶，則秒殺活動參與人數約為:

• 100 + 80 + 50 = 230 萬人

請求量

• 因促銷活動會帶來新用戶，假設帶來的新用戶數約為總用戶數的 10%，且這些用戶都是在活動要開始前半小時陸續註冊的，則註冊請求的平均 TPS 計算如下:500 萬 * 10% / (10 * 60) ≈ 833/s

• 假設兩種秒殺商品搶購的用戶比例約為 20% 充電寶 ，80% iphone 12，秒殺商品為 10 點鐘準時開放，秒殺請求平均 TPS 計算如下:充電寶: 230 萬人 * 20% = 46 萬/siphone 12: 230 萬人 * 80% = 184 萬/s

負載均衡架構設計

• 以 iphone 12 的 TPS 為 184 萬/s 來算，需要使用 F5 才有辦法支撐此性能需求。

• 假設單個服務器 (32 核) 平均處理性能約 500/s 新用戶註冊 TPS 只有 833，可忽略不計。最高秒殺請求為 184 萬/s，再加上 20% 的預留量，大約需要 3396 台服務器。

緩存架構設計

分佈式緩存直接使用 redis cluster，因為設計儲存時已經採用，主要提供秒殺商品可用數的查詢請求。

其他架構設計

可擴展架構設計

因原本架構就已經拆分成三個微服務，且有落地微服務架構，所以這次只需要增加一個秒殺微服務，並使用現行的微服務架構管理即可。

高可用架構設計

現有架構是單機房，但用戶數量已經達五百萬，可以改成同城雙中心，能做成一個邏輯機房，也能應對機房級別的災難。