1 业务分析

1.1 背景回顾

【业务背景】

设计 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. 秒杀商品仅为 200 种商品中的两种，考虑到充电宝为较为常用的商品，而 iPhone12 人气较高，活动时会有更多用户关注，需要预估部分余量。综合考虑，整个秒杀活动参与的用户大概在 日活 100 万 * 2 种商品 / 总计 200 种商品 * 10 预留参数 = 10 万左右；

2. 为应对用户在商品下单后不在规定时间内完成支付，导致最终实际有部分商品未售出的问题，可下单的商品数应略大于规划的总商品数（即允许一定程度的超售）。假设允许 10%的超售，则总计可下单的商品为：1100 个充电宝和 14 台 iPhone12。

1.2 场景分析

基于上述业务背景，待设计的秒杀系统可以分为以下几个基本场景：

1. 秒杀商品查看：在秒杀开始前 5 分钟至秒杀结束后 5 分钟这 10 分钟内，会有大量用户刷秒杀商品页准备下单、查看秒杀结果；

2. 秒杀商品下单：参加活动的 10 万用户对两种商品均进行抢购，则在秒杀开始直到秒杀结束的 2 分钟内，会有 20 万下单请求。实际需要下单的商品仅 1000 多件，因此需要在客户端进行请求拦截控制，假设最终 99%的请求因超过秒杀期限被客户端拦截，剩余 1%的请求进入服务端；

3. 秒杀订单支付：假设要求下单后 15 分钟内完成支付，下单后 15 分钟内，先完成支付的用户可实际购买成功，超过总库存规划量的订单在支付时会提示库存不足、订单转为购买失败；

4. 商品库存扣减：配合超售策略，商品库存扣减实际在订单支付成功后进行。

剩余系统与秒杀业务关键流程关联性不强，可复用现有电商平台已有系统。

2 计算架构

2.1 性能估算

业务关键场景性能估算如下：

1. 秒杀商品查看：按照参加活动每个用户在秒杀活动前后 10 分钟内平均每人请求 60 次估算，QPS 约为：10 万 * 60 / 600 秒 = 约 1 万/s；因为秒杀商品基础信息基本不会发生变化，可以通过客户端缓存拦截大部分请求，假设 99%的请求可以被客户端拦截，则实际服务端需要处理的 QPS 为：约 1000/s；

2. 秒杀商品下单：假设最终 99%的请求因超过秒杀期限被客户端拦截，剩余 1%的请求进入服务端，则下单 TPS 约为：2000 / 120 秒 = 约 20/s；

3. 秒杀订单支付：按照秒杀商品下单量级分析，支付操作对应总计约 2000 笔订单，因此订单支付的 TPS 为：2000 / (15 * 60 秒 ) = 约 3 / s；

4. 商品库存扣减：商品库存扣减实际在订单支付成功后进行，由此分析商品库存扣减 TPS 与订单支付场景 一致，约 3/s。

2.2 架构设计

秒杀系统的负载均衡及缓存架构设计如下：

负载均衡架构

缓存架构

实施落地时，秒杀系统实际是基于已有电商系统进行构建，按照目前电商整体体量来看：

1. 秒杀系统对缓存架构要求不高，因此可以完全沿用现有电商的缓存系统

2. 100 万日活的电商负载均衡架构，可能已采用基于 LVS 的负载均衡架构。如果已采用 LVS，则可以完全沿用现有电商系统的负载均衡能力，无需额外进行部署；如果电商系统本身也是基于 Nginx 部署，可以视 Nginx 负载情况，考虑是否需要额外部署秒杀系统专用的 Nginx 实例，避免秒杀活动影响普通业务。

3 存储架构

3.1 性能估算

业务关键场景性能估算如下：

1. 秒杀商品查看：参与秒杀的商品仅两件，且秒杀活动期间商品信息不会更改，可直接沿用原电商系统商品信息存储能力，秒杀系统的额外存储损耗可忽略不计；

2. 秒杀商品下单：假设最终 99%的请求因超过秒杀期限被客户端拦截，剩余 1%的请求进入服务端，则需要存储的下单数据量约为：2000 笔 * 0.5KB/笔 = 约 1MB；

3. 秒杀订单支付：按照秒杀商品下单量级分析，支付操作对应总计约 2000 笔订单，因此需要存储的支付数据量约为：2000 笔 * 0.5KB/笔 = 约 1MB；

4. 商品库存扣减：仅涉及两件商品的库存扣减，假设除存储库存最终状态外，还需存储库存扣减记录备查，总共需要存储 1114 笔 * 0.1K/笔 = 约 100KB。

3.2 架构设计

针对秒杀系统本身，对存储架构的需求如下图所示：

存储架构

其中，考虑到秒杀系统对系统整体可用性的要求，MySQL 与 Redis 需具备主备自动切换能力。

而存储量本身，如 3.1 小节分析，因为参与用户数量及商品总量较少，存储量几乎可以忽略不计。

因为秒杀系统是在已有电商系统的基础上进行构建，从上述存储量、存储可用性及请求性能需求上看，直接沿用原电商系统的存储系统即可，无需额外再部署存储节点。

4 其他架构

4.1 可扩展架构

秒杀系统涉及的微服务如下图所示：

服务划分

对现有电商系统而言：

1. 上图中的微服务都应该已经实现

2. 已经选定微服务框架（从现有业务情况来看采，不需要引入 RPC+百万量级，因此采用 Spring Cloud 更为合理），可直接复用现有的微服务框架

考虑到秒杀业务核心流程与电商通用业务流程一致，因此实际落地时需要修改优化的主要有以下几方面：

1. 修改后台管理门户前端及对应的 BFF 服务，支撑秒杀活动管理

2. 修改 APP 前端，添加秒杀倒计时、秒杀超时拦截、秒杀商品缓存逻辑

3. 由 3.1 小节分析，秒杀业务对服务端性能要求其实不高，理论上直接复用现有业务服务不会对常规业务产生影响。但是如果现有服务负载已经很高，可以考虑增加对应服务的部署实例数量（例如：商品、交易服务新增额外的服务器节点）

4.2 高可用架构

由于秒杀活动时间短，秒杀系统的高可用更多依托于现有电商系统本身的高可用能力。

由于目前整个电商系统采用单机房部署，因此不具备灾备/多活能力。本次秒杀活动本身的体量不大，专门为秒杀系统构建灾备/多活架构成本太高。

针对老板提出的“万无一失”要求，可以尝试借此机会推进真个电商系统的同城灾备机房建设。（异地多活成本太高，可先实现同城灾备，后续逐步演进至异地多活）。

4.3 大数据架构

对秒杀结果的分析可借助大数据相关组件实现。

考虑到本次活动的商品种类及数量都不多，如果现有电商系统已使用大数据相关组件（例如 clickhouse），可直接复用其组件及分析流程。如果还没有引入，可以先通过线下手动导出数据分析的方式进行分析。