架构实战营 模块九：设计电商秒杀系统

【业务背景】

你作为一个电商创业公司的架构师，负责设计 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、业务基本场景

下载、注册、登录、浏览商品、秒杀、普通购买（购物车、下单、支付等）

2、总体架构

1、日活影响：秒杀一般会进行预热和推广，日活一定会大于平时，预估为平日 5 倍，即 500W；

2、对其他业务影响：本次秒杀的主要目的是为了促进用户转化为 App 用户，所以推广主要是在小程序和 app 内进行，新注册的用户增加不明显，除秒杀外的订单增长也不会特别夸张。

主要影响到的功能：下载 app、登录、浏览商品等；

下载 app 属于一次性活动，登录状态和商品信息可以在 app 缓存数天，可以在秒杀前 3 天不上架和更新商品，现有架构基本可以满足秒杀引起的其他功能；

3、秒杀：秒杀业务是临时性活动，为了避免影响正常业务的功能和复杂度，秒杀环节的功能（主要包括浏览、库存、下单、支付等功能，物流等不属于该环节），需要独立出秒杀微服务。

2.1 架构分析

秒杀主要流程：

用户点击秒杀，服务端处理请求（大部分被丢弃，少量进入排队的队列中），返回秒杀结果，用户支付，更新库存。

排队模块： 负责接收用户的抢购请求，将请求以先入先出的方式保存下来。每一个参加秒杀活动的商品保存一个队列，队列的大小可以根据参与秒杀的商品数量（或加点余量）自行定义。

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

服务模块： 负责调用真正业务处理服务，并返回处理结果，并调用排队模块的接口回写业务处理结果。

2.2 存储架构

参与秒杀的商品类型很少，数据存储不大（2 种商品，大概 6 张图片，300K，文字和用户信息等压缩后不会超过 300K），不需要特别设计。

2.3 计算架构

1、性能估算

假设 10 秒内完成秒杀。

写入：只有 1010 个订单生成（可能会有个别订单不去支付；这部分属于用户原因，订单最终舍弃即可）；

TPS 为 101；

读取：按二八定律，假设 20%的用户，即 100W 人参与秒杀。这 100W 人在秒杀 10 秒之内完成请求，QPS：10W。但秒杀实际只有 1010 个订单，可以在终端和后台排队前进行限流，让 1010 人进入排队模块即可。

QPS 为最大 1K，最小 101。

负载均衡

缓存架构

用户一般会提前进入应用，假设这 100W 用户提前 1 分钟进入，等待秒杀开始。

QPS：100W/3600s ~=300；

综上，不涉及特别高的性能，redis 即可满足。

2.4 可扩展架构

秒杀业务是临时性活动，为了避免影响正常业务的功能和复杂度，秒杀环节的功能（主要包括浏览、库存、下单、支付等功能，物流等不属于该环节），需要独立出秒杀微服务。

2.5 高可用架构

秒杀时间短，异地多活起不到作用。

主要考虑对秒杀做限流、排队，秒杀单独部署不影响常规的商品售卖流程（可以将秒杀放在最活跃的时间段之前 1 小时，避免影响最活跃时间段的正常销售）

3、详细设计

秒杀的复杂度主要体现在限流、排队和库存（支付和订单跟正常售卖无区别）。

3.1 限流

1、终端限流：100W 用户，随机数控制，让 0.5%的用户 5000 个请求进入后台；

2、队列限流：队列可用长度=0，直接拒绝请求；（具体见排队设计）

3.2 排队

排队系统使用 Redis，而不是 MQ。

对于秒杀场景来说，一个订单只能包含一个商品，这里我们为每个秒杀商品提供一个单独的队列，这样就可以分散数据在 Redis 中的存取，多个队列可以提供更好的性能。

关于队列长度，为了保证用户能够买到商品，我们并不是把所有前台的下单请求都会放到队列里，而是根据参与活动的秒杀商品数量，按照 1:1 的比例，设置队列初始长度，这样就保证了进入队列的请求最终都能生成订单。这个可用队列长度会随着预订单进入队列，不断地减少，当数值变为 0 时，下单前台会拒绝接受新请求进入队列，直接反馈用户下单失败。

当然，如果后台订单生成异常或用户取消订单后，可用队列长度会增加，前台会重新开放预订单进入队列。也可以忽略掉这些失败的订单，允许部分商品没秒完。

3.3 库存

秒杀系统是单独的系统，每个商品的库存也是单独存放（跟常规商品区分开），按队列的可用长度展示即可。

4、微服务部署

秒杀微服务单独部署。

5、演进

第一期按上述功能实现（商品类型、数量、到达排队模块的数量按商品数量 5 倍算）；

第二期运营系统，配置商品类型、数量，动态设置通过客户端的到达排队模块的请求量/商品数量的比例。