【业务背景】

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

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

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

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

4. 老板要求万无一失。

【技术背景】

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

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

3. 目前只有单机房。

【毕设要求】

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

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

【提示】

1. 分析考虑要全面，但并不意味着架构设计要面面俱到，如果分析后认为某些设计点可以不做，就在作业最后统一说明原因即可；

2. 如果没有思路，请对照模块 9 的 IM 案例；

3. 如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断。

业务背景

秒杀商品： 1000 个充电宝，10 台 iPhone12

用户数量：日活 100 万用户

只有下载 App 才能参加秒杀活动

目前只有单机房

总体架构思路

业务场景

1、用户下载 APP 注册、登录

2、秒杀

3、下单

4、支付

思路

1、秒杀活动目的是活跃现有用户拉新用户

2、秒杀是在非常短的时间内发生并结束，不能影响现有的服务，需要独立出来

3、秒杀的商品商量有限，参加的用户很多，需要用短缓冲队列，异步处理

4、本次秒杀结束后，就不用了，建议使用云服务的自动弹性伸缩功能（根据流量大小以及服务器的负载进行弹性添加或者删除服务数量），购买服务时长短（成本考虑）。

存储架构设计

存储性能估算

1、注册 ，假设提前一个月左右通过各种广告渠道吸引用户下载 app 注册，日均注册量 2 万，30 天 60 万

2、登录，日活为 100 万，参加秒杀活动人数假设为 60%，60 万用户参与秒杀，基本会在提前半个小时作用提前登录， 登录校验用户信息 QPS 为 60 万/(30*60) = 400 ,这个量还可以不算很大

3、读取商品信息，日活为 100 万，参加秒杀活动人数假设为 60%，60 万用户参与秒杀，在秒杀前一分钟作用有好多用户在不停的刷新活动商品信息，假设每人刷新 20 次，则一分钟刷新的 QPS: 60 万 * 20/60 =20 万

4、秒杀 日活为 100 万，参加秒杀活动人数假设为 60%，60 万用户参与秒杀，TPS： 60 万

5、创建订单支付，1000 个充电宝，10 台 iPhone12 成功创建订单数量 1010 个订单

存储设计

从估算情况来讲对存储压力不大，存放注册用户信息、秒杀订单信息，MYSQL 主从架构即可，秒杀商品信息可以放到 cdn 层，商品秒杀的库存信息存放在 redis 中，采用主从即可。

1、MYSQL 主从架构（用户信息、订单信息）

2、Redis 主从架构（秒杀商品库存信息）

计算架构设计

计算性能估算

1、注册 ，假设提前一个月左右通过各种广告渠道吸引用户下载 app 注册，日均注册量 2 万，30 天 60 万,注册时间主要集中在中午 12 点到 1 点半，晚上 8 点到晚上 11 点，注册 TPS 很低

2、登录，日活为 100 万，参加秒杀活动人数假设为 60%，60 万用户参与秒杀，基本会在提前半个小时作用提前登录， 登录校验用户信息 QPS 为 60 万/(30*60) = 400 ,这个量还可以不算很大

3、读取商品信息，日活为 100 万，参加秒杀活动人数假设为 60%，60 万用户参与秒杀，在秒杀前一分钟作用有好多用户在不停的刷新活动商品信息，假设每人刷新 20 次，则一分钟刷新的 QPS: 60 万 * 20/60s =200k/s

4、秒杀 日活为 100 万，参加秒杀活动人数假设为 60%，60 万用户参与秒杀，TPS： 600k/s

5、创建订单支付，1000 个充电宝，10 台 iPhone12 成功创建订单数量 1010 个订单

负载均衡算法选择

1、登录状态一般都是保存在分布式缓存中的，将秒杀请求发送给任意服务器都可以，则其算法选择“轮询”或者“随机”。

2、查看商品信息和秒杀请求一样选择“轮询”或者“随机”算法

业务服务器数量估算

1、查询商品信息，假设 CDN 能够承载 90%的用户流量，那么剩下 10%的查询请求进入系统，则请求 QPS 为 200k/s * 10% = 20K/s，读取微博评论主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 20 台，按照 20%的预留量，机器数量为 25 台。

2、秒杀请求，因为秒杀的请求都会进入 MQ，下游的服务再消费，假设秒杀请求 qps：10k/s ，则机器的数量为 600/10=60 台，按照 20%的预留量，机器数量则为 72

负载均衡架构设计

缓存架构设计