前言

本文为 6.18 大促秒杀系统的架构设计文档

修订历史

词汇表

[可选，用于明确定义和说明一些英文缩写、术语等，请用表格来呈现，infoq 写作平台不支持表格，所以只能一个一个的列，实际编写的时候请用表格来展示]

[样例：

Reactor: 网络编程模式

Netty: 开源的网络编程框架

]

1. 业务背景

平台日活用户约为 100 万，主要渠道为自由的 app 和小程序。为了促使用户转化为 App 用户，在 6.18 当天举行秒杀活动，只有 App 上的用户才能参加活动。假设本次 6.18 活动能转化 10 万用户为 App 用户，即约有 10 万用户参加秒杀活动。

系统的业务模式如下：

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

• 6.18 活动选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；

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

• 老板要求万无一失。

基于上述业务背景，需要独立开发、部署一套秒杀系统，实现 6.18 秒杀活动的业务目标。

以下为系统边界黑盒图：

2. 约束和限制

1. 必须在 6.18 活动开始前一个月完成所有功能的开发工作，并在活动开始前，完成包括压力测试内的测试工作

2. 服务端服务使用 java 开发

3. 数据库使用 MySQL

4. 使用阿里云服务进行项目部署

5. 秒杀活动不能受区域性问题，如机房停电影响

3. 总体架构

3.1 架构分析

3.1.1 计算架构分析

在业务背景中已假设会有 10 万 app 用户参加秒杀，同时提交的瞬时并发秒杀提交为 10 万 TPS，但由于有防刷答题保护，预计瞬时 TPS 约为 1/3，即 3 万，按 3 倍预留资源，则后端服务器集群需要处理 10 万 TPS 的能力。

3.1.1.1 负载均衡架构

• 10 万 TPS 可以由 2 台 nginx 作为负载均衡器

• 使用轮询算法把请求分发到集群中的服务器

3.1.1.2 缓存架构

• App 端缓存秒杀页面的静态资源，如图片

• 秒杀页面静态资源缓存至 CDN，如图片和 html，需要更新时由管理后台触发回源

• nginx 中缓存秒杀页面的静态资源，待 CDN 回源时直接从 nginx 中读取

• 由于可秒杀的商品只有两种，所以应用内缓存秒杀详情页中可变的数据，如商品信息等

• redis 中缓存秒杀商品的库存数据

3.1.1.3 其它

• 由于可秒杀的商品数量不多，所以可以使用 redis list 存储秒杀令牌，用户发送秒杀请求时，通过 lpop 命令先尝试获取令牌，只有获取到令牌才能走后续的流程

• 为确保秒杀商品能全部售出，令牌数会设为商品数的 3 倍，即 3030 个令牌，尽量减少用户因在风控检查阶段不通过而导致商品在秒杀时段售完

• 使用 undertow 作为业务逻辑服务器，4 Cpu, 2G 内存资源，无业务处理下，单机可达 2000TPS

• 在公有云容器服务的 k8s 集群上部署应用服务，处理 10 万 TPS 共需要 50 个 pod，同时通过 istio 实现过载保护

3.1.2 存储架构

• 秒杀商品详情及库存从已有的商品库存数据库中获取，因此商品库存的存储可以直接复用。

• 秒杀商品的数量为 1010 个，因此只会产生 1010 个订单。由于在计算架构中已通过令牌及过载保护的方式对生成订单的请求进行过滤，所以存储架构只需要通过主备模式实现高可用即可。

• redis 则用 sentinel 模式实现高可用。

3.2 总体架构

3.2.1 负载均衡架构

3.2.2 缓存架构

3.2.3 单机房总架构

3.2.4 跨机房高可用架构

• 为保证活动能万无一失的进行，通过跨城双中心--远端城市方案实现灾备

• 由于秒杀活动的持续时间短，机房级别的故障发生在活动那一刻的概率很低，所以只要做好机房级别的健康检查，在活动开始前遇到故障发生时，进行人工切换即可

4. 详细设计

秒杀系统主要是在用户进入页面和点击秒杀时产生的瞬时流量会较大，所以，为减少瞬时流量直接打到自建集群上，并确保秒杀商品不会超卖，会有以下的设计：

• 静态资源，如图片、静态页面，均通过预热环节缓存至 CDN 和 nginx

• app 也会缓存静态资源

• 为防止机器人刷单，秒杀提交订单前会有答题环节

• 用户发起秒杀请求后，请求会先尝试获取事先准备好的令牌，能获取到令牌的请求则可以进入后面的支付流程

4.1 核心功能

• 核心功能序列图

4.2 关键设计

1）充分利用缓存，如 App 客户端缓存，CDN，web 服务器缓存，应用内缓存，集中式缓存等多级缓存，实现秒杀时请求的流量最小化。

2）提交秒杀请求前，通过答题环节，防止机器人刷单，也可以有效减少瞬时并发量。

3）采取下单即锁定库存的方式，在一定的时间范围内不支付，则释放库存，同一个账号只能锁定库存两次，防止恶意锁库存。

4）秒杀通行令牌存放在 redis，通过 lpop 获取，得到后即可以锁定库存；库存释放时，秒杀通行令牌也同时恢复。

5）引入网格服务，如 istio 实现熔断机制，拒绝超预期的请求流量

6）通过异地灾备模式，确保活动能如期进行

4.3 设计规范

1）项目使用 spring reactor + webflux 开发

2）生产环境用 jdk 17 运行

3）后端存储系统使用 MySQL

4）集中式缓存使用 redis

5. 质量设计

5.1 秒杀全链路测试管理后台

[必选，描述和质量相关的设计，包括：可测试性、可维护性、可观测性、成本等设计]

[样例：

5.1 消息队列管理后台

5.2 成本

]

[技巧：如果某个维度不涉及，也请在文档中说明，避免评审的时候被认为考虑不周全]

6. 演进规划

6.1 秒杀系统一期：只供用户秒杀 iphone 和充电宝，供 1010 件商品，预期转化 10 万用户为 app 用户

6.2 秒杀系统二期：增加可秒杀的商品种类及数量，预期转化 50 万用户为 app 用户