架构训练营 - 模块 9 作业

设计电商秒杀系统

【业务背景】

你作为一个电商创业公司的架构师，负责设计 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. 如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断。

业务背景

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

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

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

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

4. 老板要求万无一失。

总体架构思路

为了避免秒杀活动对线上服务造成影响，所以将商城服务和秒杀服务单独部署，并且可以在秒杀活动前预分配更多机器，在秒杀活动结束之后再下线对应的机器。

存储架构设计

用户规模存储性能预估

假设有 20%的用户每日活跃，则日活 100w 的网站实际注册用户数为 500w。

【注册】

500w 用户的注册信息。

【登录】

用户登陆之后，会长期持有登陆信息，只有 10%的日活用户需要重新登陆，则每天有 10w 的登陆请求。

【商品信息】

目前做了 10 个品类，每个品类不超过 20 个商品，每个商品的描述信息不超过 1M，则商品信息所需要的存储不超过：10*20*1M=200M。商品的描述图片则使用公有云的对象存储和 OSS 进行分发。

假设每个活跃用户每天浏览 50 个商品，则商品读取量为：100w*50=5000w/天

【秒杀】

秒杀商品信息需要与正常的商品信息分开保存，避免影响用户对非秒杀商品的影响。

【订单】

假设日活会有 10%的用户下单，则每天新增订单量为：100w*10% = 10w/天。

存储架构设计

计算架构设计

用户规模计算性能预估

假设用户活跃实际集中在 4 个小时（早上 1 小时，中午 1 小时，晚上 2 小时）

【注册】

假设日活用户中有 5%的用户为新增用户，则每日注册用户数为 100w*5% = 5w。则注册用户请求 QPS 为：5w/(4*3600)=3，可以忽略不计。

【登录】

用户会集中在抢购活动开始前 1 小时进行登陆，则登陆的 TPS 均值为：10w/3600=28。

【浏览商品】

假设每个活跃用户每天浏览 50 个商品，则商品信息的的 TPS 为：100w*50/(4*3600)=3472。

【秒杀】

假设会有 60%的活跃用户参加秒杀活动，由于商品数量较少，秒杀商品在 3 秒内抢购一空。为了避免抢购对服务端请求的压力，所以在抢购开始之前，按照 20%的概率给用户下发令牌，只有有令牌的用户才能参加抢购。

秒杀活动开始的平均 TPS 为：100w*60%*20%/3 = 4w/s。

【订单】

抢购商品较少，订单写入可以忽略不计。

计算架构之负载均衡

计算架构之缓存架构

高可用架构设计

多机房容灾，只要保存关键数据就行，例如只要保存用户数据和订单数据。

排队限流设计

首先通过提前给用户下发令牌的方式，减少了实际请求的用户数，然后使用队列的方式，减小并发请求对服务端的影响，通过反作弊分析，提前排除爬虫请求。