设计电商秒杀系统

毕业设计

【业务背景】

你作为一个电商创业公司的架构师，负责设计 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. 电商业务，正常日活 100 万用户，参考京东、淘宝等电商平台，预计年活跃用户数在 500 万规模。

参考京东 2021 年 APRU≈1600 元，预计年营收在 80 亿元规模；

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

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

4. 设计成 0、12、21 整点秒杀。高度重叠的竞争，使得各大电商注重营销的节奏错位，京东和天猫依然在 6 月 18 日，因此第三个整点选择在 21 点；

5. 每个用户只能秒杀一件商品；

6. 老板要求万无一失。

技术背景

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

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

3. 目前只有单机房。

4. 技术团队人数 100 人上下。

基本业务场景

设计思路

机房部署

• 秒杀系统实为当前电商系统的一个子系统；

• 为避免秒杀流量对当前电商系统产生不利影响，隔离原则，结合电商系统现状，只有单机房，准备把秒杀系统部署在同城的另一个机房；

• 秒杀系统中创建单独的数据库，主要包括活动商品表、活动库存表、活动订单表。

削峰限流

• 秒杀阶段的短时间流量会是平时正常流量的几十上百倍，甚至更多，不太可能也没有必要准备几十上百倍的设备及带宽，流量集中在秒杀商品页，及秒杀请求，可以用 CDN 来扛；

• 秒杀商品页为静态页提前把资源推送到 CDN；

• 假设一共 100 个 CDN 节点，每个 CDN 节点平均取前 1000 个请求，计 10 万个推给秒杀系统；

• 秒杀前 2 秒生成秒杀请求 URL，而且 URL 要经过加盐处理，防刷和作弊；

• 秒杀开始前，秒杀按钮不可用，提交秒杀请求后 5 秒内不能再次提交；

• 经过 CDN 限流，到秒杀系统后通过防刷、分层校验、限流削峰、限购、层层过滤，再经过库存查验扣减成功后的 1012 个流量进入到订单和支付流程。

库存查验 &扣减

• 采用 Redis Cluster 保存活动商品库存，两个商品库存分布在不同的切片上，提前预热，无过期时间；

• 考虑到原子性，使用 lua 脚本做库存查验+扣减处理；

• 库存扣减成功，即认为秒杀成功。

下单 &支付

• 下单失败，需要重试机制；

• 下单未支付超过一定时间，比如 5 分钟未付款，则订单取消，返回活动商品库存。

存储架构设计

用户量 & 关键行为

【用户量】

1.  正常日活 100 万，618 大促当日日活 300 万用户（参考其它电商平台 2021 年数据，大部分为正常日活的一点几到二倍之间）。

2. 假设 10% 的用户参与秒杀，即 30 万用户。也可以在 CDN 做边缘计算得出实际数量。

【关键行为】

1. 登录/注册；

2. 进入秒杀商品页；

3. 秒杀；

4. 付款。

用户行为建模和性能估算

【注册】

用户注册信息存在于当前电商系统。

【登录】

618 大促日活 300 万，即当天读取用户信息为 300 万 QPS，当前电商系统提供支撑。

【进入秒杀商品页】

进入秒杀页面，假设参与秒杀的用户提前 5 分钟开始陆续进入秒杀页面，则页面请求为 1000QPS。提前生成静态页面，并推送到 CDN，由 CDN 提供支撑。

校对时间，进入页面后，需要每秒向服务器校时，则最高请求为 30 万 QPS。由 CDN 提供支撑。

【秒杀】

秒杀请求，30 万用户参加秒杀，30 万 TPS。

下单，一共 1012 个用户可以成功秒杀到商品，1012 条订单数据，这个量级可以忽略不计。

活动库存，两个商品，一共两条记录，忽略不计。

【付款】

一共 1012 个用户可以成功秒杀到商品，假设用户在 10 秒内完成付款，即 101TPS。

1012 条交易数据，这个量级可以忽略不计。

存储架构

数据量很少，主备数据库架构即可满足要求。

实际上没有必要再另外部署数据库，直接使用当前电商系统的数据库构架即可。

计算架构设计

计算性能估算

【注册】

当前电商系统提供支撑。

【登录】

618 大促日活 300 万，即当天读取用户信息为 300 万 QPS，当前电商系统提供支撑。

【进入秒杀商品页】

进入秒杀页面，假设参与秒杀的用户提前 5 分钟开始陆续进入秒杀页面，则页面请求为 1000QPS。提前生成静态页面，并推送到 CDN，由 CDN 提供支撑。

校对时间，进入页面后，需要每秒向服务器校时，则最高请求为 30 万 QPS。由 CDN 提供支撑。

【秒杀】

秒杀请求，30 万用户参加秒杀，30 万 TPS。

下单，一共 1012 个用户可以成功秒杀到商品，如果 1 秒完成，则 1012TPS，可以忽略不计。

【付款】

一共 1012 个用户可以成功秒杀到商品，假设用户在 10 秒内完成付款，即 101TPS。

计算架构之负载均衡

秒杀时，由每个 CDN 节点选前 n 个请求，共计 10 万个请求放给秒杀系统，Nginx 即可以满足要求。

计算架构之缓存

CDN

• 秒杀商品的静态页面及资源提前推送到 CDN，用来扛流量；

• 服务器校时也放在 CDN 处理，这里也可以考虑同时做活动参与人数的统计。

APP 缓存

• 静态资源在前端做 APP 缓存处理。

WEB 容器缓存

• WEB 容器缓存主要提供给 CDN 回源访问。

分布式缓存

• 秒杀商品信息；

• 秒杀商品库存；顺便提一下，因为是 2 个秒杀商品，缓存系统需要采用分片集群，这里采用 Redis Cluster；

• 秒杀参与用户，5 秒失效，拦截重复提交。

计算架构之高可用

【限流】

限制 10 万流量到达秒杀系统

• 秒杀时，CDN 做限流处理，放 10 万请求到秒杀系统。

对同一 IP 限流，1 个 IP 在 1 秒内只能访问一次，不考虑公司员工出口 IP 问题

• 在 CDN 配置 IP 访问频率；

• 在 Nginx 通过 limit_req_zone 关键字。

对同一用户限流，5 秒内只能访问一次

• 在应用层，通过 Redis 配和处理。

限制 2 万合法流量到达秒杀服务

• 使用漏桶算法处理。

【排队】

秒杀成功的请求，进入到排队系统，并返回给前端排队号，前端在获取到排队号后就开始轮询以获取查询 Token，订单业务服务器订阅排队队列并生成订单，再把查询 Token 及订单相关信息写入 Redis，前端用查询 Token 访问订单业务服务器，返回结果后进入支付流程。

要说明的是，一个商品对应一个队列，所以充电宝和 iPhone 12 需要分开的 2 个队列。

其中消息队列产品，参考本次秒杀商品数量，RocketMQ 比较适合，但也要考虑当前公司在用的消息队列产品，比如当前在用 Kafka，那就没有必要再部署 RocketMQ，事实上因为数据量小直接采用 Redis 也可以。

可扩展架构设计