架构实战营模块九作业

【业务背景】

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

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

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

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

4. 老板要求万无一失。

【技术背景】

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

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

3. 目前只有单机房。

【毕设要求】

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

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

业务基本场景

1. 账号与手机号绑定，每个手机号只能注册一个账号；

2. 生成待支付订单后锁库存，支付完成后扣库存，订单超时释放库存。待支付订单有效期 1 分钟；

3. 秒杀商品页是一个独立页面，提前一天开放，但只有倒计时时刻才能点击“立即抢购”按钮，秒杀当天的 0:00、12:00、22:00 3 个整点时刻开启秒杀；

4. 秒杀商品每人限购一件；

架构设计思路

1. 平时日活 100 万，我们假设秒杀当天的日活是平时的 3 倍即 300 万用户会访问系统，因此秒杀系统仍然按照百万用户级别来设计；

2. 秒杀的持续时间很短，只有 6.18 当天的 3 个整点时刻，因此不需要考虑秒杀的异地多活；

3. 秒杀业务仍然是百万用户的系统，不会颠覆现有架构设计，按照架构设计的三原则及可扩展思想，我们只需独立出秒杀的微服务即可，且秒杀服务是对已有服务的调用编排，其需要考虑的是高性能、高可用问题；

4. 秒杀的核心在于排队和限流，因为最终只有 1010 个名额，系统设计上可只放进来 5000 个抢购请求（多预留一部分流量），其余请求直接返回友好提示文案；

5. 秒杀业务的绝大部分流量在秒杀商品页，这个页面可做成静态页，并做多级缓存；

存储架构设计

存储性能估算

假设 300w 用户有 50%的用户参与秒杀，基于该数据进行估算：

【注册】

预估因秒杀活动而单独注册的用户占比较少，且这类用户也都是在活动开始前陆续注册的，因此秒杀业务不必单独考虑注册的存储性能问题。

【登录】

假设 300w 用户中有 30%因 session 过期需在秒杀当日重新登录，则登录读取用户信息是 300*30%=90w，因此秒杀业务不必单独考虑登录的性能问题。

【秒杀商品页】

秒杀商品只有充电宝和 iphone12 两种商品，可做成静态页做多级缓存，因此不存在 DB 的读取性能问题。

【秒杀】

1010 个秒杀名额，最终只放进来 5000 个抢购请求，则订单量不超过 5000。

【支付】

同订单量，1010 个秒杀名额产生的支付数据量不超过 5000。

存储架构设计

计算架构设计

计算性能估算

假设 300w 用户有 50%的用户参与秒杀，基于该数据进行估算：

【注册】

预估因秒杀活动而单独注册的用户占比较少，且这类用户也都是在活动开始前陆续注册的，因此注册 TPS 很小可忽略不计。

【登录】

假设 150w 用户中有 20%因 session 过期在秒杀前 30 分钟重新登录，则登录 QPS 为 150*20%/(30*60) ≈ 160，因此登录没有计算性能问题。

【秒杀商品页】

假设参与秒杀的用户提前 5 分钟开始陆续进入秒杀页，其中 30%的用户是首次进入秒杀页（非首次浏览走 APP 缓存），则真正产生的 QPS 为 150w*30%/(5*60) = 1500。

【秒杀】

假设在 60s 内秒杀商品被抢完，则秒杀 TPS 为 150w/60s = 2.5w；最终只有 5000 个请求被放进来，则下单 TPS 不超过 5000。

【支付】

因为只有 5000 个请求被放进来，假设用户在 10s 完成支付，则支付 TPS 最大不超过 5000/10s = 500。

负载均衡

缓存架构