1. 业务场景

负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：

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

2. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone12 作为秒杀商品；

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

4. 老板要求万无一失。

【技术背景】

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

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

3. 目前只有单机房。

2. 业务数据分析

1. 设计电商秒杀系统，不能对原有的电商系统中的业务产生影响；

2. 6.18 的日活的用户数量会很大，预估 6.18 当日的日活量为 200W【根据 2022 年 6.18 京东日活量对比说明】

3. 秒杀商品的总数为 1010 个，共计产生 1010 个订单

4. App 下载、商品浏览、购买、支付的行为会增加

5. 秒杀商品绝对不能超卖。

3. 总体架构设计

(一) 涉及到的业务模块

App 下载、购买秒杀商品、商品查看、排队查询、登录。

(二) 服务提前处理要求

• App 挂载到各大应用商城，对此下载性能不对整个电商系统产生影响；

• 商品查看和秒杀页面中涉及到的图片和文件提起部署到服务器上，并配置相应的 CDN 服务确保大量客户在浏览时，前端页面不产生卡顿现象。

• 秒杀系统的核心设计是限流和排队。

(三) 功能模块服务分析

秒杀服务主要通过前端的限流、网关的令牌桶限流、和服务的排队机制实现，同时后端服务对于每一个每一笔数据处理都采用悲观锁模式。计划前端和网关限流，最后只允许 6000-8000 之间的访问量进入。主要包含网关服务、排队服务、监听服务、秒杀服务四个模块。

1. 网关服务：主要用于限流处理，实现令牌桶算法，对进入的流量进行限制。

2. 排队服务：主要用于客户获取队号和 token，将客户上送的请求转化为 ID+队号，推送给队列。再有监听服务推送给秒杀服务生成 token。

3. 监听服务：主要用于监听队列中的消息及时推送给秒杀服务用于生成 token.

4. 秒杀服务：生成 token，校验 token，以及购买产品

(四) 关联系统影响处理

要求秒杀对原有电商业务不产生影响，而且是临时性服务。即要求独立建设秒杀服务系统，即独立部署模式

3.1 存储设计

数据量分析：秒杀系统的商品共计两种类型，购买人数 1010，产生订单 1010 个，生成 token 共计 8000 左右（使用 redis 存储，响应速度 10000/s），商品的图片数量较少。因此涉及到入库的数据较少，不用再使用分库分表的方案；数据库只需采用 MySQL 主备模式，确保数据高可用；使用分布式缓存 Redis 数据库确保访问速率，其采用主从+哨兵部署模式。具体实现如下图：

注：不在考虑同城双活异地灾备的情况，本身只为单机房；同时秒杀的业务均为临时型业务且持续访问的时间不长，不值得在为此建立双活或者灾备机房。

3.2 高性能设计

访问性能分析：日活评估为 200W 人，预估参与秒杀人员大约 20%的人，即 40W 人；同时预估秒杀整体的时间为 10S。即 要求 TPS=4w/s，最后限流达使 TPS 降到 800/S 机器数量：两台网关服务器 Nginx+lua 实现令牌桶限流功能，4 台服务器【四台均部署秒杀服务，两台部署排队服务，两台监听服务】。应用服务器共计 6 台【4C/12G】。

(一) 负载均衡

通过 DNS 负载到两台网关服务器上(只部署 Nginx 服务)，Nginx 在负载到相依的服务上，负载策略使用轮询机制

(二) 缓存设计

app 端采用 App 缓存储存商品的描述信息和图片信息，Web 容器主要为小程序提供图片缓存处理。使用分布式缓存用于存储 token 数据。

(三) 排队、限流

通过前端的限流【数据的丢弃】、网关服务的令牌桶限流、以及服务端的排队服务，最终保障秒杀服务的 TPS<=800/S[总计耗时为 10S]，即最终共计生成 8000token，超过此数量不再生成 token。排队主要通过队列的模式实现，确保队号和 token 的有效性，避免通过接口渠道刷，要求 token 和 ID[用户的唯一标识]+队号进行绑定。最终通过数据库的悲观锁确保数量不超买。

3.3 应用实现方式

采用微服务模式部署。

4. 可扩展设计

上述的配置足够支持 4 倍的当前业务需求量【适当的调整限流的百分比】，如果后期业务量的翻倍增加，可以增加网络的机器数量【根据当前的比例进行调整】以及动态调整 token 的生成总数。