背景

【业务背景】

你作为一个电商创业公司的架构师，负责设计 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. 正常的日活大约 100 万用户，假设 50%的用户参加秒杀活动，则有 50 万用户参加秒杀；

2. 假设 10 秒钟秒杀结束，那么 QPS 为：50 万/10 秒=5 万/秒；

3. 秒杀商品一共有 1000 个充电宝，10 台 iphone 12 手机，那么只有前 1010 名用户能抢到秒杀商品；

业务场景

1. 浏览秒杀商品

2. 请购秒杀商品

总体架构思路

1. 秒杀商品的页面内容使用 CDN 进行存储和访问，减少网关和后端服务的访问压力；

2. 在网关上对秒杀发起地址进行限流，限每秒 500 个请求，3 秒钟可抢完所有秒杀商品；

3. 因为所有秒杀从 APP 发起，因此只需要在 APP 上对限流进行统一处理，处理方式是：遇到限流错误时，直接返回失败页面，此后该 APP 终端的请求直接在 APP 端拦截；

4. 当秒杀商品被抢购完时，向所有 APP 推送秒杀活动结束的消息，APP 收到此消息后将新的秒杀请求全部拦截在 APP 端，不对服务器发起请求；

5. 由于网关进行了限流，因此，后端服务没有增加多少压力，使用 redis 集群进行秒杀的查询和存储即可；

6. 秒杀的主要压力在于网关，假设一台 nginx 网关每秒能处理 3 万个请求，那么需要增加两个 nginx 服务器来应对秒杀活动；

存储架构设计

秒杀活动的商品、库存及抢购数据保存在 redis 集群：

计算架构设计

要支持新增的每秒 5 万的并发请求，需要添加 2 条 nginx 服务器，架构图如下：

高可用设计

由于已落地微服务架构，因此使用现有的架构设计即可，将秒杀服务配置为多个实例。