模块九作业

1. 背景

【业务背景】

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

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

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

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

4. 老板要求万无一失。

【技术背景】

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

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

3. 目前只有单机房

2. 业务基本场景

2.1 注册

• 正常的日活大约 100 万用户，假设日活用户占总量的 30%，则实际注册用户数为 300 万。

• 假设秒杀活动带来 20%的用户增长，新增注册数为 60 万，则总注册用户数达 360 万。

2.2 登录

• 正常的日活大约 100 万用户，登录次数为 100 万。

• 假设 60%的已有用户以及新增的 60 万用户参与秒杀，则登录次数为：300 万 * 60% + 60 万 = 240 万。

2.3 商品浏览

• 假设正常情况下平均每个用户浏览 30 个商品，则读取商品信息次数为：30 * 100 万 = 3000 万。

• 假设秒杀时浏览量翻一倍，则读取商品信息次数为：2 * 30 * 240 万 = 14400 万。

2.4 下单

• 假设正常情况下订单转化率为 5%，则每天新增订单为：100 万 * 5% = 5 万。

• 假设秒杀时订单转化率翻倍，则秒杀期间每天新增订单为：240 万 * 10% = 24 万。

2.5 支付

• 正常情况下支付数为：5 万。

• 秒杀情况下支付数为：24 万。

3. 总体架构思路

• 由于前期已经落地了微服务，本期项目目标只是新增秒杀功能，因此同样以微服务的形式开发秒杀服务即可。

• 通过业务基本场景的分析，估算平时平台的实际注册用户数为 300 万，考虑秒杀活动带来的增长预估总用户数为 360 万，因此按照原有系统百万规模进行秒杀系统的架构设计即可。

4. 存储架构设计

4.1 存储性能估算

4.1.1 注册

• 注册信息总计：360 万。

4.1.2 登录

• 秒杀登录记录数为：240 万。

4.1.3 商品浏览

• 假设每件商品信息包含 10 张图片，每张图片大学为 5M，商品描述大小 100K，则秒杀商品大小为：20 * 10 * (10 * 5M + 100/1024M) = 10GB。

4.1.4 下单

• 秒杀期间订单数量为：24 万。

4.1.5 支付

• 秒杀期间支付信息总数为：24 万。

4.2 存储架构

• MySQL 采用主从架构，存储用户数据及订单数据。

• 秒杀商品信息及库存信息存储在 Redis 中，满足高并发及高可用性，并方便后续扩展。

5. 计算架构设计

5.1 计算性能估算

5.1.1 注册

• 假设秒杀活动带来的用户增长在 7 天内完成，则新用户注册的 TPS 为：60 万 / (7 * 24 * 60 * 60) = 0.99。这个量原有的设计就可以支撑。

5.1.2 登录

• 假设参与秒杀的用户在秒杀开始前 30 分钟内完成登录，则登录 QPS 为：240 万 / (30 * 60) = 1333。

5.1.3 商品浏览

• 假设秒杀前后 10 分钟内，商品浏览量达到顶峰，则读取商品信息的 QPS 为：14400 万 / (2 * 10 * 60) = 12 万。

5.1.4 下单

• 假设秒杀商品在 1 秒内抢完，则秒杀订单的 TPS 为：1010。

• 假设秒杀期间产生的所有订单在 1 小时内产生，则所有订单的 TPS 为：24 万 / (60 * 60) = 67

5.1.5 支付

• 假设秒杀商品在 5 分钟内完成支付，则支付信息 TPS 为：1010 / (5 * 60) = 3.4。

• 假设秒杀期间产生的所有订单在 15 分钟内完成支付，则支付信息 TPS 为：24 万 / (15 * 60) = 267。

5.2 计算架构

5.2.1 计算架构之负载均衡

• 可以根据用户量的增长情况，将 Niginx 演进为 LVS。

5.2.2 计算架构之缓存架构

• 由于只有 App 用户可以参加秒杀活动，因此可以将活动静态内容提前加载到 App 缓存中。

• 参与秒杀的商品信息及库存信息均保存在 Redis 分布式缓存中，活动过后再同步到 MySQL 数据库中。

5.2.3 计算架构之接口高可用

• 限流：采用令牌桶算法，并随机丢弃部分秒杀请求。

• 排队：秒杀成功的请求先缓存到 Redis 中，再依次逐一处理。

6. 其它架构设计

• 前期已经落地微服务，基础设施可以重用；同时由于秒杀活动属于临时业务，因此秒杀服务以单独微服务的形式拆分出来。

• 基于上述估算，无需为了秒杀活动考虑多机房。