毕业设计：设计电商秒杀系统

1. 分析

1.1 背景回顾

【业务背景】

一个电商创业公司的电商系统，需要 开展 6.18 大促的营销活动，需要对 6.18 大促秒杀系统进行架构设计，该公司的业务模式如下：

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

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

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

• 老板要求万无一失。

【技术背景】

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

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

• 目前只有单机房。

【业务量级分析】

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

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

【技术分析】

• 作为一个电商初创公司，可用经费有限，F5 什么的就不要想了，也就是 Nginx 或是 LVS 了

• 估计公司技术人员也不会超过 20 人,要做一个秒杀系统，能投入的人员就算 10 个吧，这也是特别理想的估算了，

• 还有一条关键信息目前只有单机房，也就是说机房是自己运维的，服务器也是自己使用自己采购的机器。但是秒杀系统有个很大的问题，它瞬时流量很大，但不会一直使用，没准秒杀一次效果不好以后就不用了。原本的业务不能停，而且不太可能就为这一次秒杀活动采购一批服务器，所以服务器的问题比较偏向使用【云服务】，这个当然要找老板确认，只要老板愿意花钱买新服务器以及承受单机房的风险就好。

• 团队偏向 Java 技术栈，已经落地微服务，我们就认为是 SpringCloud 全家桶了.

• 秒杀入口是自家的 APP，但由于秒杀只允许 APP 访问，临近秒杀可能 APP 下载可能会飙升，万一把应用商店挤挂了，虽然作为一个初创电商可能性很低，但为了满足万无一失最好还是在官网提供一下 APP 下载的途径，其他入口都增加该途径的链接。

1.2 场景分析

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

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

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

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

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

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

2. 架构设计

2.1 性能估算

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

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

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

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

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

2.2 总体架构设计

系统整体采用微服务架构，按照业务域，对系统做一级的粗粒度划分。

2.3 部署图

2.4 限流设计

秒杀限流采取以下三种方式的结合，做到万无一失：

• 请求端限流：APP 根据设定的参数（结合监控数据，运维平台动态设置阈值和参数），40W->10W

• 接入端限流:Nginx 根据设定的规则过滤掉部分请求，（结合监控数据，运维平台动态设定过滤比例）,10W->1W

• 排队限流：排队服务基于漏桶算法实现，实际由 redis 的队列来实现排队服务非常合适。一个商品一个队列。

3. 存储架构设计

3.1 存储性能估算

由于我们的场景是秒杀，而且由于货物数量极其有限，其实存储基本需要特殊设计，可以直接与原有的服务对接即可。

由于秒杀没有新的用户因此用户数据保持不变。商品和货物数据也基本保持不变。不需要进行性能估算。

3.2 存储架构设计

mysql 作为主要存储，主从自动切换+自建机房备份，为了进一步降低秒杀过程中事务冲突，每种商品都单独一个表存储。我们的 redis 只用作缓存。

3.2.1 缓存设计

基本情况：

• app 缓存+web 容器缓存+分布式缓存。

• 详情页等图片信息采用 APP 缓存+web 容器缓存的方式。

• 秒杀状态，库存，排队等情况采用 redis 存储，由于秒杀流量极大，redis 采用 redis cluster 方式部署，估计需要 5 个节点。

4. 高可用设计

为确保在秒杀开启后，大流量冲击下万无一失，确保高可用，除了自建机房，需要购买一定的异地云服务，将数据同步到云中，发生本地宕机情况下，自动切换到云端。同时将请求放入消息队列，以应对高频请求，降低服务端压力。

5. 可扩展设计

上面已经分析过了，作为初创电商公司，投入的技术人员可能不超过 30 个，后端人员算 15 个，根据三个火枪手原则，拆分的服务不宜超过 5 个。

服务拆分如下所示：

• 订单服务

• 商品服务

• 支付服务

• 营销服务

• 运维监控服务