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

【业务背景】

你作为一个电商创业公司的架构师，负责设计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 倍算）；

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