【業務背景】
你作為一個電商創業公司的架構師，負責設計 6.18 大促秒殺系統的設計，你們的業務模式如下：
1. 你們挑選選品各大電商平臺上暢銷和好評的商品進行銷售，每個品類不超過 20 個商品，目前做了 10 個品類；
2. 本次 6.18 秒殺選擇了 1000 個充電寶，10 臺 iPhone 12 作為秒殺商品；
3. 正常的日活大約 100 萬用戶；
4. 老闆要求萬無一失。
【技術背景】
1. 技術團隊以 Java 為主，已經落地了微服務架構；
2. 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程式，為了促進使用者轉化為 App 使用者，只有下載 App 才能參加秒殺活動；
3. 目前只有單機房。
業務基本場景
對前面的業務背景描述，進行核心業務場景假設，秒殺系統核心系統包括：
- 秒殺商品詳情繫統，
- 秒殺交易系統
- 商品庫存系統
- 支付系統
儲存架構設計
儲存效能估算
- 使用者資訊
日活 100W 的系統，假設日活使用者佔 10%，註冊使用者有 100/10% = 1000W
- 商品資訊
正常售賣商品數：10 個品類，每個品類不超過 20 個商品，總商品數目為：10*20=200 個商品，假設定期會對這些熱銷和好評的商品進行更新，更新評率為每週更新所有 200 個商品，為滿足未來 2 年的增長，200*52*2=20000+商品
由於秒殺系統僅 618 使用，因此無需隔離熱點商品資訊，如後續需要演進為每日秒殺的系統，則可以做單獨的熱點商品儲存和正常商品隔離
- 庫存資訊
假設每個上架的商品都是有庫存的，庫存記錄數大致 20000+
秒殺庫存，是否需要設計隔離的熱點商品庫存也看是否會演進每日秒殺的系統
- 訂單資訊
假設該電商系統 100W 日活使用者，實際每日下單的使用者佔 50%，每日產生 50W 訂單，滿足未來 2 年增長 365*2*50=3.65 億訂單資料
- 支付資訊
假設下單的使用者都進行了支付，少量因為訂單因為各種填寫錯誤等原因未支付的訂單，因此支付賬單約 3.65 億
儲存架構設計
資料特點分析：
- 商品資訊相對固定，包含商品介紹，圖片等靜態資源資訊，讀多寫少，適合透過讀寫分離的方式，提高讀效能的支撐，
- 庫存資料，頻繁讀寫，對應秒殺場景，單庫無法支撐寫請求時，可透過庫存拆分的方式分擔寫壓力
- 訂單資料，支付資料未來可能持續增長，且資料量較大（上億記錄），存在明顯的冷熱特性，因此考慮對資料進行分片，按月拆分, 先做水平分表，後續再考慮分庫
根據上面的分析，儲存架構設計包括
- 分為商品、庫存資料庫、訂單庫、支付賬單庫，可先採用 MySQL 主從架構
- 商品詳情頁動靜資源分離，靜態資源透過引入 CDN 儲存進行加速
- 使用者資訊、一些動態快取的內容，以及秒殺過程中排隊，可以考慮引入 Redis, 採用多機的 Cluster 架構
計算架構設計
計算效能估算
- 檢視商品詳情：假設 100W 使用者全部參與秒殺，檢視商品的 QPS 為 100W
- 下單秒殺：比如增加答題等設計攔截下單請求，下單過程分散到 1~3 秒，下單 TPS 大致到 30W
- 支付：支付過程由於一般較長，假設一般要 10 秒完成，支付 TPS 為 10W
計算架構-負載均衡設計
採用多級負載均衡架構
- 第一級 DNS 採用專門的秒殺域名，和主站分離
- 第二級採用 LVS 叢集，第三級採用 nginx 叢集
計算架構-快取設計
採用多級快取架構設計
1.CDN 快取靜態商品資訊，攔截大部分商品 QPS
2.APP 端快取，秒殺預告預先放出了商品資訊，可快取部分資源到 APP 內部快取
3.應用程式本地快取，可存商品資訊等
4.分散式快取 RedisCluster 叢集，儲存使用者資訊，商品資訊，秒殺限流任務佇列
