作业内容

设计电商秒杀系统

【业务背景】

你作为一个电商创业公司的架构师，负责设计 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. 老板要求万无一失。

技术背景

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

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

3. 目前只有单机房。

业务基本场景

1. 秒杀商品必须用户登录后才能够购买，但查看商品不需要登录。

2. 微信小程序中加入对应商品的推荐以及广告信息，点击过后打开 APP 进入秒杀页面。

3. 每个用户能且仅能秒杀一个同品类的商品，已经提交的秒杀商品不能重复提交。

4. 同品类商品的秒杀时间均为同一时间段。

5. 商品库存的占用以提交订单为准，不以商品支付为准。在商品订单提交后，支付未成功时，该商品库存视为已被占用。在商品订单提交后，订单又超过了支付的等待时间，该商品库存需要释放。

6. 当商品库存消耗完，或者秒杀时间过期时。商品秒杀结束，剩余商品的库存自动归入其正常商品的库存中去。

存储架构设计

百万用户规模存储性能估算

【注册】

百万用户注册信息。日活 100 万，按照 40%日活率计算。注册用户数为：250 万

【登录】

日活用户 100 万，则每日登录时的用户信息访问：QPS 数量为 100 万/天

【商品查看】

假设 100 万用户，目前所有商品数量 10 个品类，且每个品类不超过 20 个商品，所有商品总共大约在，150~200 个时间，则本次秒杀商品 100%会被人查看到。所以每日商品查看的 QPS 数量为：每日上线人数*秒杀商品种类=QPS 次数。200 万/天。

【购物车】

假设 100 万用户中有 10%的用户对于秒杀商品感兴趣，可能会将该秒杀商品加入购物车。则对于购物车的 TPS 数量为：10 万/天

【商品秒杀】

假设商品都顺利售卖出去，则会产生：1010 个商品的订单信息。

假设商品推广时间为 7 天，秒杀时间为 1 小时。所有平台用户基本可以都浏览到该秒杀商品，且有需求的用户会参加该商品的秒杀活动。则可对定秒杀时间段，会有平台 10%的用户参与秒杀活动。则该时段的 TPS 数量为：250 万（用户数）*10%（参加人数）= 25 万/s.

计算架构设计

百万用户规模计算性能估算

【商品秒杀】

假设商品推广时间为 7 天，秒杀时间为 1 小时。所有平台用户基本可以都浏览到该秒杀商品，且有需求的用户会参加该商品的秒杀活动。则可对定秒杀时间段，会有平台 10%的用户参与秒杀活动。则该时段的 TPS 数量为：250 万（用户数）*10%（参加人数）= 25 万/s.

其它架构设计

高可用架构可采用同城双机房模式。