妳作為壹個電商創業公司的架構師，負責設計 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 億
數據特點分析：
根據上面的分析，存儲架構設計包括
采用多級負載均衡架構
采用多級緩存架構設計
1.CDN 緩存靜態商品信息，攔截大部分商品 QPS
2.APP 端緩存，秒殺預告預先放出了商品信息，可緩存部分資源到 APP 內部緩存
3.應用程序本地緩存，可存商品信息等
4.分布式緩存 RedisCluster 集群，存儲用戶信息，商品信息，秒殺限流任務隊列