模块 9- 设计电商秒杀系统

一、背景

1.1【业务背景】

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

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

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

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

4. 老板要求万无一失。

1.2【技术背景】

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

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

3. 目前只有单机房。

1.3【业务基本场景】

1.只有下载 App 才能参加秒杀活动。

2.秒杀页面对畅销和好评的商品进行推荐销售。

3.订单需 30 分钟内支付。

4.支付依赖第三方支付平台。

二、设计思路

2.1.独立部署

• 避免对其他业务产生影响，秒杀系统和 Redis 集群独立部署，使用独立的域名。

2.2.减少到后端服务器的请求数

• 系统做动静分离，静态资源上传到 CDN。

• 利用 APP 缓冲。

2.3.流量消峰

• 秒杀时通过答题，防止秒杀器和延长用户提交请求的时间。

2.4.限流

• APP 端随机丢弃部分请求，只有 20%请求进入后端服务。

• 如用户秒杀成功，APP 端将不可再参与秒杀活动。

• 后端服务随机丢弃部分请求，只有 20%请求最后能访问 redis 集群中的库存数据进行秒杀，可在后端系统配置请求通过率并实时生效。

2.5.库存减扣

• 秒杀商品件数缓存到 redis 集群中，每一种商品都创建一个 list，该商品的秒杀件数有多少，list 中的元素就有多少个，每次下单就从 list 中弹出一个元素，防止超卖。

• 秒杀成功的用户放入 SET 中，防止多次抢购。

三、存储架构设计

3.1 存储性能估算

• 下载

iOS 安装包 50M，Android 安装包 60M，APP 安装包已上传 CDN。

• 注册

因为 6.18 大促的前期宣传，注册数每天增加 3 万，但数据量没有质的飞越，可以忽略不计。

• 登录

正常日活用户 100 万，6.18 大促登录数据是每天 200 万。

• 浏览商品

2 件秒杀商品，200 件推荐商品。静态资源需要提前推送 CDN，秒杀商品件数缓存到 redis 集群中。

• 秒杀

1. 6.18 大促登录数据是每天 200 万，假设有 60%的用户参加秒杀，每个用户参加 2 次秒杀答题，题库数据量为：200 万 * 60% *2 = 240 万。需要题库数缓存到 CDN 中。

2. 充电宝和 iPhone 12 合计 1010 台 ，1010 条下单记录。

• 支付

同下单，合计为 1010 条记录。

3.2 存储架构设计

• 支付和订单处理，数据量不大，沿用原有 Mysql 主备。

• 避免对其他业务产生影响，Redis 集群独立部署。

四、计算架构

4.1 计算性能估算

• 下载

6.18 大促登录数据是每天 200 万，假设有 60%的用户参加秒杀，同时其中 40%用户需要下载 APP，下载多发生在秒杀前 8 小时内。

下载量：200 万 * 60% *40% =48 万。

下载量 QPS：48 万 / (8 * 60 * 60) ≈ 16.8 次/秒

因下载是非核心业务，这里先假设原来的 CDN 可以满足需求。

• 注册

每日新注册用户不到 3 万，可以忽略。

• 登录

6.18 大促登录数据是每天 200 万，假设登录时间集中在早晚 4 小时，登录 TPS 均值：200 万 / 14400 = 140。

• 浏览商品

6.18 大促登录数据是每天 200 万，假设有 60%的用户参加秒杀，秒杀前 5 分钟开始进入商品浏览页面，查看秒杀商品和推荐商品，假设每人查看 10 个商品。

查询数量为：200 万 * 60% *10 = 1200 万查询。

查询 QPS 为： 1200 万 / (5 *60) = 4 万/秒

• 秒杀

1. 6.18 大促登录数据是每天 200 万，假设有 60%的用户参加秒杀，20%请求进入后端服务，因为有答题，秒杀 2 秒完成，因此秒杀 QPS 均值：200 万 * 60% *20% / 2 = 12 万。

2. 因为后端服务保留 20%的请求，因此访问 redis 集群中秒杀件数的 TPS 均值：12 万 *20% =2.4 万。

3. 1010 条下单记录，2 秒内完成（假设秒杀持续了 2 秒），下单 TPS 均值：1010 /5 =505。

• 支付

支付预计在 1 分钟内完成，TPS 为：1010 /60 ≈ 16.9 ，可以忽略不计。

4.2 计算架构之负载均衡

4.3 计算架构之缓存架构

五、可扩展架构设计

5.1 微服务拆分

5.2 、内部服务间通过消息队列进行调用

为了避免下单、支付等服务产生数据库死锁，给每种商品建立一个消息队列，消峰、解耦的同时避免数据库资源的竞争。