大数据与高并发 (一) ----------- 秒杀架构设计

我就是我 2024-04-01 06:25 111阅读 0赞

#### 目录 ####

*  一、业务介绍
 *  二、业务特点
 *   *  1. 瞬时并发量大
     *  2. 库存量少
     *  3. 业务简单
 *  三、技术难点
 *   *  1. 现有业务的冲击
     *  2. 直接下订单
     *  3. 页面流量突增
 *  四、架构设计思想
 *   *  1. 限流
     *  2. 削峰
     *  3. 异步
     *  4. 缓存
 *  五、整体架构
 *  六、客户端优化
 *   *  1. 秒杀页面
     *  2. 防止提前下单
 *  七、API 接入层优化
 *  八、SOA 服务层优化
 *  九、秒杀整体流程图
 *  十、总结

--------------------

## 一、业务介绍 ##

![在这里插入图片描述][0e25082b2f5942e69e6b3f5bae20d1c7.png]

> 什么是秒杀？通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动

比如说京东秒杀，就是一种定时定量秒杀，在规定的时间内，无论商品是否秒杀完毕，该场次的秒杀活动都会结束。这种秒杀，对时间不是特别严格，只要下手快点，秒中的概率还是比较大的。

淘宝以前就做过一元抢购，一般都是限量 1 件商品，同时价格低到「令人发齿」，这种秒杀一般都在开始时间 1 到 3 秒内就已经抢光了，参与这个秒杀一般都是看运气的，不必太强求。

## 二、业务特点 ##

![在这里插入图片描述][44d89c457cf74bbf9867ee6321aa935c.png]

### 1. 瞬时并发量大 ###

秒杀时会有大量用户在同一时间进行抢购，瞬时并发访问量突增 10 倍，甚至 100 倍以上都有。

### 2. 库存量少 ###

一般秒杀活动商品量很少，这就导致了只有极少量用户能成功购买到。

### 3. 业务简单 ###

流程比较简单，一般都是下订单、扣库存、支付订单。

## 三、技术难点 ##

![在这里插入图片描述][be3e2eb29e1c44de9dfe7ce2a32ffd62.png]

### 1. 现有业务的冲击 ###

秒杀是营销活动中的一种，如果和其他营销活动应用部署在同一服务器上，肯定会对现有其他活动造成冲击，极端情况下可能导致整个电商系统服务宕机。

### 2. 直接下订单 ###

下单页面是一个正常的 URL 地址，需要控制在秒杀开始前，不能下订单，只能浏览对应活动商品的信息。简单来说，需要 Disable 订单按钮。

### 3. 页面流量突增 ###

秒杀活动开始前后，会有很多用户请求对应商品页面，会造成后台服务器的流量突增，同时对应的网络带宽增加，需要控制商品页面的流量不会对后台服务器、DB、Redis 等组件的造成过大的压力。

## 四、架构设计思想 ##

![在这里插入图片描述][9e172463f83d4721ac83ddb6ec2b9163.png]

### 1. 限流 ###

由于活动库存量一般都是很少，对应的只有少部分用户才能秒杀成功。所以我们需要限制大部分用户流量，只准少量用户流量进入后端服务器。

### 2. 削峰 ###

秒杀开始的那一瞬间，会有大量用户冲击进来，所以在开始时候会有一个瞬间流量峰值。如何把瞬间的流量峰值变得更平缓，是能否成功设计好秒杀系统的关键因素。实现流量削峰填谷，一般的采用缓存和 MQ 中间件来解决。

### 3. 异步 ###

秒杀其实可以当做高并发系统来处理，在这个时候，可以考虑从业务上做兼容，将同步的业务，设计成异步处理的任务，提高网站的整体可用性。

### 4. 缓存 ###

秒杀系统的瓶颈主要体现在下订单、扣减库存流程中。在这些流程中主要用到 OLTP 的数据库，类似 MySQL、SQLServer、Oracle。由于数据库底层采用 B+ 树的储存结构，对应我们随机写入与读取的效率，相对较低。如果我们把部分业务逻辑迁移到内存的缓存或者 Redis 中，会极大的提高并发效率。

## 五、整体架构 ##

![在这里插入图片描述][60b19f4464104c12b14c9d5b7fdae3fa.png]

## 六、客户端优化 ##

客户端优化主要有两个问题：

### 1. 秒杀页面 ###

秒杀活动开始前，其实就有很多用户访问该页面了。如果这个页面的一些资源，比如 CSS、JS、图片、商品详情等，都访问后端服务器，甚至 DB 的话，服务肯定会出现不可用的情况。所以一般我们会把这个页面整体进行静态化，并将页面静态化之后的页面分发到 CDN 边缘节点上，起到压力分散的作用。

### 2. 防止提前下单 ###

防止提前下单主要是在静态化页面中加入一个 JS 文件引用，该 JS 文件包含活动是否开始的标记以及开始时的动态下单页面的 URL 参数。同时，这个 JS 文件是不会被 CDN 系统缓存的，会一直请求后端服务的，所以这个 JS 文件一定要很小。当活动快开始的时候（比如提前），通过后台接口修改这个 JS 文件使之生效。

## 七、API 接入层优化 ##

客户端优化，对于不是搞计算机方面的用户还是可以防止住的。但是稍有一定网络基础的用户就起不到作用了，因此服务端也需要加些对应控制，不能信任客户端的任何操作。一般控制分为 2 大类：

**限制用户维度访问频率**

针对同一个用户（ Userid 维度），做页面级别缓存，单元时间内的请求，统一走缓存，返回同一个页面。

**限制商品维度访问频率**

大量请求同时间段查询同一个商品时，可以做页面级别缓存，不管下回是谁来访问，只要是这个页面就直接返回。

## 八、SOA 服务层优化 ##

上面两层只能限制异常用户访问，如果秒杀活动运营的比较好，很多用户都参加了，就会造成系统压力过大甚至宕机，因此需要后端流量控制。

对于后端系统的控制可以通过消息队列、异步处理、提高并发等方式解决。对于超过系统水位线的请求，直接采取「Fail-Fast」原则，拒绝掉。

## 九、秒杀整体流程图 ##

![在这里插入图片描述][3202e0cd0a3a414cbcdd3dc71fa065ab.png]  
秒杀系统核心在于层层过滤，逐渐递减瞬时访问压力，减少最终对数据库的冲击。通过上面流程图就会发现压力最大的地方在哪里？

MQ 排队服务，只要 MQ 排队服务顶住，后面下订单与扣减库存的压力都是自己能控制的，根据数据库的压力，可以定制化创建订单消费者的数量，避免出现消费者数据量过多，导致数据库压力过大或者直接宕机。

库存服务专门为秒杀的商品提供库存管理，实现提前锁定库存，避免超卖的现象。同时，通过超时处理任务发现已抢到商品，但未付款的订单，并在规定付款时间后，处理这些订单，将恢复订单商品对应的库存量。

## 十、总结 ##

核心思想：层层过滤

尽量将请求拦截在上游，降低下游的压力  
充分利用缓存与消息队列，提高请求处理速度以及削峰填谷的作用

[0e25082b2f5942e69e6b3f5bae20d1c7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/442dda875957401fb8ed5137d9b414a8.png
[44d89c457cf74bbf9867ee6321aa935c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/e45e2a390d4b47cbbaba1802356ae467.png
[be3e2eb29e1c44de9dfe7ce2a32ffd62.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/537ab59d7ef24b9bb927de813d5d20b0.png
[9e172463f83d4721ac83ddb6ec2b9163.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/7b8c79d2a3114feb91e583a199ffd2ad.png
[60b19f4464104c12b14c9d5b7fdae3fa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/6d249baa9b9b490bbc0d8f6a5558c3b1.png
[3202e0cd0a3a414cbcdd3dc71fa065ab.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/e3d3c554513f42e19bc1fe895f1f6e02.png