模块 9 设计电商秒杀系统

1.业务背景

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

6.18 秒杀：本次选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；

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

要求：老板要求万无一失。

电商秒杀系统架构设计

2.技术背景

1. 技术团队以 Java 为主，已经落地了微服务架构；

2. 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

3. 目前只有单机房。

微服务框架选型

后端团队目前技术栈统一为 JAVA,使用 spring 全家桶能够快速出成果；框架选择使用嵌入 SDK 的方式，选择 使用 spring cloud 提供的网关，熔断，服务注册。

秒杀业务基本场景

秒杀商品详情——》秒杀（下单）——》支付

3.用户关键行为

1.用户登录后，在商品详情页面查看和搜索商品，可以提前预约想要秒杀的商品。

2.秒杀时间到达前十分钟，提醒已经预约秒杀的用户秒杀活动即将开始。

3.用户进入商品详情页面点击秒杀按钮进行“秒杀”。

4.进入订单页面填写订单信息提交订单。

5.下单成功后五分钟内进行支付。

主要流程

4.性能预估

日活 100 万用户，预计参与秒杀活动用户量为 30%，秒杀用户量为 30 万。

刷新详情页

秒杀活动前会有大量用户不断刷新商品详情页面，一遍第一时间看到秒杀信息进行下单，大部分用户会在活动开启前一分钟内疯狂刷新页面。假设人均刷新页面为 5 次，

开启前最后 30 秒。假设全部用户抢统一款商品。

QPS:30w*5/30=5w

下单（秒杀）

活动开启后，假设所有用户在 10 秒内进行提交订单，假设在 10s 内平均每个用户提交两次。

TPS：30w *10*2=6w

付款

只有抢到商品的用户才能付款，TPS/QPS 太小，可以忽略不计。

5.架构设计

5.1 存储架构

秒杀系统主要关键活动在于秒杀，数据库存储并不大，商品信息，用户信息可以从已完成的电商系统获取；

使用 mysql 作为存储数据库。存储秒杀订单、活动数据。使用主从即可

5.2 缓存架构

5.2.1 多级缓存

秒杀活动开始前，用户不断刷新页面查询活动信息，秒杀活动开始后，短时间内会拥入很大流量，为了快熟处理响应，使用 redis 前缓存活动信息，Web 服务提供的静态资源放到了 CDN（CDN 是全国都有的服务器，客户端可以根据所处位置自动就近从 CDN 上拉取静态资源，速度更快），来大大减轻抢购瞬时秒杀域名的负担。

5.2.2 分布式缓存

使用 redis cluster 作为分布式缓存，秒杀的模式下 redis 的读远大于写，使用一主多从的模式保证读取性能。热点数据直接冲 redis 中读取，在活动前先进行缓存预热，将活动信息提前

放入 redis 中。

5.2.3 扣库存

因为减库存会产生比较大的并发更新请求直接在数据库中扣减同一秒杀商品的库存数据，这样会导致线程之间竞争 InnoDB 行锁。数据库中针对同一行数据的更改是串行执行的，如果某一个线程没有释放锁之前，其余的线程会阻塞，这样并发越高等待的线程就越多。这样的情况会影响数据库的 TPS。前面缓存了库存的数据，扣库存采用直接在库存中进行。扣减过程如下

5.3 计算架构

5.3.1 负载均衡

根据秒杀预估，使用 nginx 能够应对，通关和秒杀服务使用集群的方式提高算力。

5.3.2 接口高可用

使用漏桶算法进行限流

5.3.3 使用队列进行排队

5.4 可扩展架构设计

秒杀服务通过微服务独立部署，不影响其他应用，如果业务扩展可通过扩展服务实现。

5.5 总体架构

下图是整体架构图，主要分成 5 层，Nginx 主要用于负载均衡和方向带来，web 成主要用于接口汇集和页面；RPC 层为各个微服务，包括秒杀系统服务和电商微服务；存储层主要是 redis 和 mysql。

6.其他设计

6.1 秒杀隔离

秒杀流量是突发式的，而且流量规模很难提前准确预估，如果混合在一起，势必会对普通商品的交易造成比较大的冲击；所以电商系统和秒杀系统的流量应该隔离开，

防止秒杀流量串访到普通商品交易流程上，带来不可预估的灾难性后果。隔离只要是业务隔离，数据隔离，系统隔离。

6.2 消峰限流

10 台 iPhone 12 的库存，不管是 10 万用户和 1 万个用户进行秒杀，对电商而言，带来的经济效益和社会影响力不会有时被差距；

相反，用户越多，一方面消耗机器资源越多；另一方面，越多的人抢不到商品，平台的客诉和舆情压力也就越大，所以我们需要提前对流量进行管控。

6.2.1 使用验证码

避免用户短时间内多次发送秒杀请求，也能有效避免疯狂刷单。

6.2.2 消息队列

当大量请求到来时，服务使用消息队列对请求进行排队，避免服务被瞬间冲垮。如果订单已经被抢完，剩余的请求快速响应已售完；

如果秒杀请求超出队列，多进来的请求进行有损消峰。