设计电商秒杀系统

【业务背景】

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

架构设计方案

1. 业务基本场景

1. 选品 10*20 商品进行 618 销售

2. 通过下载注册 app 可以进行 618 秒杀

3. 针对 1000+10 件商品进行秒杀

4. 正常日活 100 万用户，大促期间用户日活会增长

2. 总体架构思路

1. 已经落地微服务架构，团队 Java 为主。因为属于创业团队，需要尽量控制成本，在现有微服务架构基础上扩展秒杀微服务，并且尽量不影响现有微服务。

2. 618 大促有时间限制，尽量利用团队熟悉的技术，并使用现有的基础服务。针对秒杀场景，建议租用云服务器做为排队服务器以及消息队列服务（如 Kafka 或云厂商提供的队列服务）采用按需计费模式。

3. 单机房部署升级为同城双机房灾备模式

电商秒杀系统整体架构图

3. 存储架构设计

3.1 存储性能估算

【注册】

假设有 300 万注册用户。

【登录】

大促期间大概有 50%的用户为日活用户，大约 150 万。

【浏览商品】

10 个品类，每个品类 20 个商品，共 10*20=200 个商品供浏览。

【秒杀】

假设活跃用户对 1000 个充电宝+10 台 iphone12 进行秒杀，则秒杀商品 1000+10=1010。

假设 30%活跃用户都参与秒杀，平均每人在秒杀期间发起 20 个秒杀请求

秒杀消息=150 万*30%*20 = 900 万。

【订单】

假设注册用户有 50%都会参与购买商品，平均每个用户购买 5 件商品

订单消息=300 万*50%*5 = 750 万。

【支付】

假设秒杀成功用户都进行支付，则支付消息为 1000+10 = 1010。

3.2 存储架构设计

MySQL 主备（用户数据+商品数据+购买记录）

300 万注册信息，150 万登录请求，10*20 = 200 商品数据， 300 万*50%*5 = 750 万购买记录

Redis 主备（秒杀数据+商品数据）

秒杀商品有 1000+10=1010，商品数据有 10*20 = 200

4 计算架构设计

4.1 计算性能估算

【注册】

每日新用户注册不到 1 万可以忽略

【登录】

大促期间大概有 50%的用户为日活用户，大约 150 万。每日集中在秒杀前 30 分钟登录

TPS = 150 万 / 30*60 = 0.08 万/s

【浏览商品】

10 个品类，每个品类 20 个商品，共 10*20=200 个商品供浏览。150 万登录用户，平均每人浏览 20%的商品，并且都集中在 30 分钟的时间内。

QPS = 150 万*200*20%/30*60 = 3.33 万/s

【秒杀】

假设活跃用户对 1000 个充电宝+10 台 iphone12 进行秒杀，则秒杀商品 1000+10=1010。

假设 30%活跃用户都参与秒杀，平均每人在秒杀期间的 5 分钟内发起 20 个秒杀请求

TPS=150 万*30%*20/5*60 = 3 万/s

【订单】

非秒杀购买商品 TPS 可以忽略不记，秒杀购买商品 TPS=1000+10=1010/s

【支付】

假设秒杀成功用户都进行支付，则支付消息为 1000+10 = 1010。

4.2 计算架构设计

4.2 计算架构之缓存架构设计

多级缓存设计：

1. App 端缓存

2. CDN 缓存静态资源（假设已有 CDN，没有可以暂时先不增加）

3. web 容器缓存

4. 秒杀应用进程内缓存（由于时间局部性），其他服务不需要进程内缓存

5. 分布式缓存采用现有 redis 主备

5 其他架构设计

5.1 可扩展架构设计-微服务拆分

5.2 高可用架构设计-同城双中心

先考虑灾备（比较简单容易），之后再考虑双活（在灾备基础上改造相对容易）

5.3 秒杀场景排队架构设计

采用请求缓存 + 同步改异步 + 请求端轮询

排队架构示意图

排队具体实现方案

（Kafka 可以换成云服务商提供的现有消息队列服务）

排队服务设计

【排队模块】

负责接收用户的抢购请求，将请求以先入先出的方式保存下来。每一个参加秒杀活动的商品保存一个队列，队列的大小根据参与秒杀的商品数量（1000+10）定义。

【调度模块】

负责排队模块到服务模块的动态调度，不断检查服务模块，一旦处理能力有空闲，就从排队队列头上把用户访问请求调入服务模块。

【服务模块】

负责调用真正业务处理服务（订单支付服务），返回处理结果，并调用排队模块的接口回写业务处理结果。