1. 背景描述

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. 目前只有单机房

2. 业务基本场景

用户登录系统，并参与秒杀活动。

3. 架构设计

3.1 总体架构思路

日活百万级客户的应用：

1. 预计用户是在千万级

2. 预计原有 APP 覆盖率应该不足 50%

3. 此次参与秒杀后，能提升 10%~20%（增长 150W 安装量，共 650W 安装）

4. 参与秒杀的 APP 达到 300W

3.2 存储架构设计

3.2.1 性能估算

300W 客户参与秒杀，但是无需参与秒杀的客户信息都需要存储，共 1000 个产品，可在网关限流 1W 即可：

• 登录：300W 登录信息

• 秒杀：1W 条秒杀数据

3.2.2 架构设计

1. 1000W 用户注册信息

2. 300W 登录请求

3. 1W 秒杀请求

3.3 计算架构设计

3.3.1 性能估算

• 登录：假设登录时间集中在秒杀前 2H，登录 TPS：300W / 2 / 3600 = 420

• 秒杀：假设秒杀集中在 10 秒内，故秒杀请求：300W / 10 = 30W；被网关过滤后的实际请求为：1W / 10 = 1000

3.3.2 负载均衡架构设计

1. 网关流量要能抗 40W 起，可以整 2 个 F5 或者是 LVS

2. 剩下的流量都不是很大：按单个实例 500 计算

3. 登录 TPS 在 600，2 个实例即可

4. 实际秒杀控制在 1000，3 个实例即可

3.3.3 缓存设计

虽然实际到真正服务节点的秒杀请求仅 1000 TPS，但有 300W 客户会参与秒杀，都会看到秒杀页面，故而引入 APP 缓存、CDN 以及 Web 容器缓存，其中有 90% 的客户预计会在秒杀前 5min 进入到秒杀页面，此时结合 APP 缓存、CDN 以及 Web 容器缓存，能够控制流量。