设计电商秒杀系统

【业务背景】

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

存储架构设计

存储性能估算

正常日活有 100 万用户，假设活动期间日活为平时两倍 200 万。

【注册】

假设注册用户每天活跃的有 40%，则有 200w / 40% = 500w 注册用户信息。

【登录】

假设活动当天登录用户为平时两倍，则登录用户有 200w。

【商品】

假设每个类目都有 20 个商品，则商品数量为 10*20 = 100。

【秒杀】

秒杀商品只有两个，1000 个充电宝，10 台 iPhone 12。

【下单】

假设活动当天，平均每个商品有 5w 用户下单，则订单数为 100*10w = 500w。

【支付】

假设活动当天，所有创建的订单有 80% 完成了支付，则支付数为 500w*80% = 400w。

存储架构设计

MySQL 主备，包含 500w 注册用户信息，200w 用户登录请求，500w 订单信息，400w 支付信息。

Redis 主备，存储 100 商品信息以及商品库存信息。

计算架构设计

计算性能估算

【注册】

大部分参与活动用户都是日常已注册用户，所以活动期间注册 TPS 不高。

【登录】

假设活动当天登录用户为平时两倍，且假设登录时间集中两小时内，登录 TPS 均值：200w / 7200 ≈ 280/s。

【商品】

假设在活动期间两小时内，平均每个商品有 40% 用户查看过。则查看商品 QPS：10*20*200w*60% / 7200 ≈ 2.5w/s。

【秒杀】

假设每个秒杀商品有 50% 用户参与秒杀，且假设秒杀在 10s 内完成。则秒杀 TPS 为 2*200w*50%/10 = 20w/s。

【下单】

秒杀商品下单只有秒杀成功才可以下单，则秒杀下单 TPS 为 1010/10 ≈ 100/s。

活动当天其他商品订单数为 500w，假设下单时间集中在四小时内，则下单 TPS 为 500w/14400 ≈ 350/s。

【支付】

活动当天支付数为 400w，假设支付时间集中在四小时内，则支付 TPS 为 400w/14400 ≈ 280/s。

负载均衡架构

缓存架构

秒杀高可用计算架构

假设单台业务服务器处理能力是 1000/s。

【用户服务】（包含注册、登录）

需要 2 台机器（一台作预留量）。

【商品服务】

商品信息提前预热，存储在分布式缓存中。则商品服务需要 30 台机器（5 台作预留量）。

【秒杀服务】

秒杀请求采用限流手段。

请求端限流采用限制请求次数，用户同一个秒杀商品参与一次后抢购按钮变灰 1 秒；

接入端限流采用限制同一用户请求频率，同一用户每隔一秒对每个秒杀商品只能发起一次请求；

微服务采用漏桶算法，每个秒杀商品对应漏桶容量为秒杀库存数量的 2 倍；

则秒杀实际 TPS 为 (1000+10)*2=2020/s，秒杀服务需要 5 台机器（2 台作预留量）。

【订单服务】（包含下单、支付）

需要 2 台机器（1 台作预留量）。