电商秒杀系统

【业务背景】

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

业务背景

秒杀商品： 1000 个充电宝，10 台 iPhone12

用户数量：日活 100 万用户

准时参与秒杀的用户： 100 万 * 60% = 60 万

业务分析

业务场景

注册：部分新用户为了参加秒杀，下载 app 进行注册。

登陆：用户会在秒杀活动开始前 5 分钟集中登陆。

浏览商品：用户会在登陆一直到秒杀活动结束期间不断刷新秒杀商品。

秒杀下单：用户会在秒杀活动开始时集中下单秒杀商品。

支付：只有抢到的用户才需要支付。

性能预估

注册业务在活动之前，量少且分散，暂且忽略。

秒杀场景下，系统所需支持的最大流量即秒杀开启时的峰值。开启后用户会随着时间逐渐减少，即须支撑的 QPS：60 万。

登陆 QPS：60 万 / 5 / 60 = 2000 QPS，忽略

支付忽略不计

存储架构设计

数据量并不大，用户数据，数百商品数据，订单数据使用 Mysql 主备方式可以满足业务需求。针对秒杀商品主要是读场景，使用 Redis 主从结构提高 QPS 即可满足。

计算架构设计

高可用设计

分级缓存

分别在 APP 端，Nginx 端进行商品信息缓存以减轻应用服务器和 Redis 的压力。

多层限流

针对秒杀下单操作，100 万用户抢 1010 件商品，命中率仅为 1/1000。因此可以分别在 APP 端和 Nginx 端进行 90% 和 50% 的限流。

业务需要处理的 TPS：60 万 * 10% * 50% = 3 万

异地备份

异地双活确保活动万无一失

1. 计算节点双机房切换

2. 单机房做 Mysql 主备，同时在异地机房进行备份