架构实战营模块 9 作业

设计电商秒杀系统

【业务背景】

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

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

2. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone12 作为秒杀商品;

3. 正常的日活大约 100 万用户;

4. 老板要求万无一失。

【技术背景】

1. 技术团队以 Java 为主，已经落地了微服务架构;

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

3. 目前只有单机房。

【毕设要求】

1. 设计完整的架构，例如存储、负载均衡、缓存、高可用、可扩展等;

2. 大约 10 页以内的 PPT，每页 PPT 说明一项设计，包括架构设计和设计理由，无需详细解释备选方案。

一、整体思路

1. 正常日活约 100 万用户，按每天活跃用户占 40%，推算出总用户量为 250 万左右。

   假设用户中有 30% 参加秒杀活动，即秒杀参与用户为 175*0.3=50 万。

   假设下单超 15 分钟未支付，则系统自动取消订单。

   商品共 10 个品类，每类不超过 20 种商品，总量不超过 200 种商品，假设每个商品的图文信息不超过 3M，则所有产品信息最大为 200*3M=600M。

二、存储架构设计

2.1 性能估算

【注册数据】

250 万用户注册信息。

【登录数据】

日活百万，登录时读取用户信息是每天 100 万 QPS。

【商品数据】

总商品不超过 200 种，产品信息不超过 600M，可忽略不计。

【交易数据】

用户日活 100 万，假设每个用户每天下单一次，则每天新增 100 万笔交易记录。

2.2 架构设计

三、计算架构设计

3.1 性能估算

【注册】

每日新增注册用户可忽略。

【用户登录】

每日 100 万用户登录，假设登录时间集中在 4 小时，则登录 TPS 为 100 万/14400≈70。

【商品查看】

假设秒杀用户在活动前 1min 内平均刷新 3 次活动商品秒杀信息，则秒杀信息查看的 QPS 为 50 万*3/60s≈25000。

【商品下单】

假设秒杀用户秒杀请求有 1%真正请求服务端，且秒杀商品在 1s 内完成抢购，则秒杀商品下单 TPS 为 50 万*1%/1s≈5000。

【商品付款】

付款主要依赖第三方支付平台，可以不考虑。

3.2 架构设计

3.2.1 负载均衡设计

3.2.2 缓存设计

秒杀商品的图文信息可以在活动开始前提前下发到 APP 缓存，WEB 容器主要缓存静态资源。

秒杀库存数量可提前放在 Redis 队列中。

四、可扩展架构设计

五、高可用架构设计

由于目前只有单机房，可用性瓶颈受该机房决定。由于目前是单机房部署，老板要求的万无一失的情况下需考虑做同城双中心架构。

六、大数据架构设计

考虑到业务场景目前不涉及数据检索数据分析这类需要大数据集市的技术，因此可以暂时不考虑。但随着业务发展可以在数据量不大的情况下引入 ClickHouse 来满足大数据场景。ClickHouse 兼容 SQL 维护简单、集成 OLAP 分析、性能较好。后期数据量大的情况下可以从 ClickHouse 向 Hadoop + Spark 演进。