业务背景

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：

• 你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类；

• 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；

• 正常的日活大约 100 万用户；

• 老板要求万无一失。

技术背景

• 技术团队以 Java 为主，已经落地了微服务架构；

• 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

• 目前只有单机

业务基本场景

• 注册：提前 7 天预热，引导用用户将在 APP 端注册。

• 登录：秒杀前会出现集中登录的情况

• 浏览商品：商品信息已经固定，因此提前通过 CDN 缓存好，商品数量通过 redis 进行存储。

• 下单：不能发生超卖

• 付款：付款使用第三方支付

存储架构设计

• 数据库使用主从复制，使用读写分离。

• 存储商品信息

• 存储订单信息

缓存架构设计

• Redis 缓存使用 Redis cluster

• 存储库存信息

• 分布式锁保障不超卖

计算架构设计

计算性能预估

注册： 100W 日活，基本上都会参与秒杀，其中 30%的人用户为非 APP 用户，100*30%=30W，假设注册 高峰为晚 8 点至 11 点，3 个小时，平均 TPS 为：30W/3/3600=28

登录: 假设 80%的人，在秒杀前 1 小时进行登录。QPS: 100W*80%/1/3600=222

浏览：假设 80%的人在秒杀开始前 1 秒进行刷新，QPS:100W*80%=80W ，通过 CDN 解决

下单：假设 80%的人在秒杀开时点击下单，TPS:100W*80%=80W，通过限流解决，只允许前 2000 名进行 调用下单接口。

付款：最终可付款用户只有 1010 人，付款使用第三方结算平台

复载均衡

缓存架构