高并发系统的三把利器

青旅半醒 2023-09-27 23:46 91阅读 0赞

**目录**

1.限流

2.缓存

2.1.缓存的使用场景

3.降级

3.1.什么是降级？

3.2.服务降级方式

4.其他高并发手段

4.1. 集群

4.2.拆分

4.2.1 应用拆分

4.2.2 数据库

4.3. 静态化

4.4.削峰

4.5.限流

5.总结

参考

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

保护高并发系统的三大利器：**限流、熔断降级、缓存**

*  **限流：**控制系统的请求量，防止系统被过度压力而崩溃。
 *  缓存：将一些常用的数据存储在内存中，减轻数据库的压力，提高系统的响应速度。
 *  降级：当系统不能承受更多的请求时，可以有意识地关闭一些不必要的功能或服务，以保证核心功能的正常运行。

## **1.限流** ##

限流是保护高并发系统的三把利器之一。限流在很多场景中用来限制并发和请求量。实现系统限流的方式有很多种，比如令牌桶算法、漏桶算法等。

采用限流策略来控制用户的请求速率

**限流常用的几种算法**

**1）计数器限流**

你要是仔细看了上面的内容，就会发现上面举例的每秒阈值1000的那个例子就是一个计数器限流的思想，计数器限流的本质是一定时间内，访问量到达设置的限制后，在这个时间段没有过去之前，超过阈值的访问量拒绝处理，举个例，你告诉老板我一个小时只处理10件事，这是你的处理能力，但领导半个小内就断续断续给你分派了10件事，这时已经到达你的极限了，在后面的半个小时内，领导再派出的活你是拒绝处理的，直到下一个小时的时间段开始。

**2）漏斗限流**

漏斗限流，意思是说在一个漏斗容器中，当请求来临时就从漏斗顶部放入，漏斗底部会以一定的频率流出，当放入的速度大于流出的速度时，漏斗的空间会逐渐减少为0，这时请求会被拒绝，其实就是上面开始时池塘流水的例子。流入速率是随机的，流出速率是固定的，当漏斗满了之后，其实到了一个平滑的阶段，因为流出是固定的，所以你流入也是固定的，相当于请求是匀速通过的

## 2.缓存 ##

### **2.1.缓存的使用场景** ###

*  经常需要读取的数据
 *  频繁访问的数据
 *  热点数据缓存
 *  IO 瓶颈数据
 *  计算昂贵的数据
 *  无需实时更新的数据
 *  缓存的目的是减少对后端服务的访问，降低后端服务的压力

**1）CDN 缓存**

*  `CDN` 的全称是 `Content Delivery Network`，即内容分发网络。`CDN` 是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。`CDN`的关键技术主要有内容存储和分发技术。
 *  `CDN` 它本身也是一个缓存，它把后端应用的数据缓存起来，用户要访问的时候，直接从`CDN` 上获取，不需要走后端的 `Nginx`，以及具体应用服务器 `Tomcat`，它的作用主要是加速数据的传输，也提高稳定性，如果从 `CDN` 上没有获取到数据，再走后端的`Nginx`缓存，`Nginx` 上也没有，则走后端的应用服务器，`CDN`主要缓存静态资

**2）应用缓存：**

**内存缓存**

在内存中缓存数据，效率高，速度快，应用重启缓存丢失

**磁盘缓存**

在磁盘缓存数据，读取效率跟内存比较，磁盘缓存稍低，但应用重启缓存不会丢失**3）**

**3）多级缓存**

在整个应用系统的不同层级进行数据的缓存，多层次缓存，来提升访问效率；比如：`浏览器 -> CDN -> Nginx -> Redis -> DB (磁盘、文件系统)`

随着业务的不断增加，服务器性能很快又到达瓶颈

## 3.降级 ##

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的

### 3.1.什么是降级？ ###

服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。

### 3.2.服务降级方式 ###

延迟服务：定时任务处理、或者mq延时处理。

页面降级：页面点击按钮全部置灰，或者页面调整成为一个静态页面显示"系统正在维护中......"。

关闭非核心服务：比如电商关闭推荐服务、关闭运费险、退货退款等。保证主流程的核心服务下单付款就好。

写降级：比如秒杀抢购，我们可以只进行Cache的更新返回，然后通过mq异步扣减库存到DB，保证最终一致性即可，此时可以将DB降级为Cache。

读降级：比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存

## 4.其他高并发手段 ##

### 4.1. 集群 ###

*  有一个单体应用，当访问流量很大无法支撑，那么可以集群部署，也叫单体应用**「水平扩容」**，原来通过部署一台服务器提供服务，现在就多部署几台，那么服务的能力就会提升。
 *  部署了多台服务器，但是用户访问入口只能是一个，比如 `www.evanshare.com`，所以就需要 **「负载均衡」**，负载均衡是应用集群扩容后的必须步骤，集群部署后，用户的会话 `session` 状态 要保持的话，就需要实现 `session` 共享。

### 4.2.拆分 ###

#### 4.2.1 应用拆分 ####

应用的拆分：分布式 （微服务）

单体应用，随着业务的发展，应用功能的增加，单体应用就逐步变得非常庞大，很多人 维护这么一个系统，开发、测试、上线都会造成很大问题，比如代码冲突，代码重复，逻辑错综混乱，代码逻辑复杂度增加，响应新需求的速度降低，隐藏的风险增大，所以需要按照 **「业务维度进行应用拆分，采用分布式开发」**；

应用拆分之后，就将原来在同一进程里的调用变成了远程方法调用，此时就需要使用到 一些**「远程调用技」** `httpClient`、`hessian`、`dubbo`、`webservice` 等；

随着业务复杂度增加，我们需要采用一些开源方案进行开发，提升开发和维护效率，比 如 `Dubbo`、`SpringCloud`；

通过应用拆分之后，扩容就变得容易，如果此时系统处理能力跟不上，只需要**「增加服务 器即可」**（把拆分后的每一个服务再多做几个集群）

#### 4.2.2 数据库 ####

**1）数据库拆分**

数据库拆分分为：**「垂直拆分和水平拆分 （分库分表）」**

**「按照业务维度把相同类型的表放在一个数据库，另一些表放在另一个数据库」**，这种方式 的拆分叫**「垂直拆分」**，也就是在 不同库建不同表，把表分散到各个数据库

比如产品、订单、用户三类数据以前在一个数据库中，现在可以用三个数据库，分别为 **「产品数据库、订单数据库、用户数据库」**，这样可以将不同的数据库部署在不同的服务器上，提升单机容量和性能问题，也解决多 个表之间的 IO 竞争问题

根据数据行的特点和规则，将表中的**「某些行切分到一个数据库，而另外的某些行又切分 到另一个数据库」**，这种方式的拆分叫**「水平拆分」**

单库单表在数据量和流量增大的过程中，大表往往会成为性能瓶颈，所以数据库要进行**「水平拆分」**

**2）**读写分离 + 主从复制

3）数据库优化

### 4.3. 静态化 ###

对于一些访问量大，更新频率较低的数据，可直接定时生成静态 html 页面，供前端访问，而不是访问 jsp

常用静态化的技术：`freemaker`、`velocity` 定时任务，每隔 2 分钟生成一次首页的静态化页面

页面静态化首先可以大大提升访问速度，不需要去访问数据库或者缓存来获取数据，浏览器直接加载 `html` 页即可

页面静态化可以提升网站稳定性，如果程序或数据库出了问题，静态页面依然可以正常 访问

### 4.4.削峰 ###

削峰本质上是更多地延缓用户请求，层层过滤用户的访问需求，**遵从“最后落地到数据库的请求数要尽量少”的原则**

1.  **限流算法**：通过限制单位时间内请求的数量或速率，来控制访问流量。常见的限流算法包括令牌桶算法和漏桶算法。
2.  **缓存**：将一部分数据缓存在内存中，减少对数据库的访问次数，从而降低服务器压力。
3.  **负载均衡**：将访问流量分散到多台服务器上，避免单一服务器过载，提高系统的可用性和稳定性。
4.  **异步处理**：将一些耗时的操作异步处理，如发送邮件、生成报表等，避免阻塞主线程，提高系统的并发能力。
5.  **CDN加速**：通过将静态资源缓存在CDN节点上，加速用户对静态资源的访问，降低服务器压力

### 4.5.限流 ###

通过削峰策略来平衡供需，从而保证系统的正常运行

像漏斗一样，尽量把数据量和请求量一层一层地过滤和减少，需要查询的用户，在缓存中能能查询到需要的信息，无需通过每次查询数据库，那么最后留下的，就是真正需要成交的客户，大大减轻DB的读写压力

![e9f9390e61120f924ea2cc285e8d14c3.png][]

**1）分层过滤的核心思想**

*  通过在不同的层次尽可能地过滤掉无效请求。
 *  通过CDN过滤掉大量的图片，静态资源的请求。
 *  再通过类似Redis这样的分布式缓存，过滤请求等就是典型的在上游拦截读请求。

**2）分层过滤的基本原则**

*  对写数据进行基于时间的合理分片，过滤掉过期的失效请求。
 *  对写请求做限流保护，将超出系统承载能力的请求过滤掉。
 *  涉及到的读数据不做强一致性校验，减少因为一致性校验产生瓶颈的问题。
 *  对写数据进行强一致性校验，只保留最后有效的数据。

最终，**让“漏斗”最末端(数据库)的才是有效请求**。例如：当用户真实达到订单和支付的流程，这个是需要数据强一致性的。

## 5.总结 ##

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一。

提高系统并发能力的方式，方法论上主要有两种：**垂直扩展（Scale Up）与水平扩展（Scale Out）**。前者垂直扩展可以通过提升单机硬件性能，或者提升单机架构性能，来提高并发性，但单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是后者：**水平扩展。**

同时结合一些策略达到分流、限流的目的

1.对于秒杀这样的高并发场景业务，**最基本的原则就是将请求拦截在系统上游，降低下游压力**。如果不在前端拦截很可能造成数据库(mysql、oracle等)读写锁冲突，甚至导致死锁，最终还有可能出现雪崩等场景。

2.划分好动静资源，静态资源使用CDN进行服务分发。

3.充分利用缓存(redis等)：增加QPS，从而加大整个集群的吞吐量。

4.高峰值流量是压垮系统很重要的原因，所以需要RocketMQ消息队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息推送出去。

以上，为个人工作之余一些浅薄看法，记录下来，与诸位共享，不足之处，多多指点，感激不尽

## 参考 ##

[\[1\]][1]高并发场景，你要如何实现系统限流？

[\[2\]][1]分布式高并发服务三种常用限流方案简介

[\[3\]][1] 九师兄的博客 - 高并发之限流 RateLimiter使用

[e9f9390e61120f924ea2cc285e8d14c3.png]: https://img-blog.csdnimg.cn/img_convert/e9f9390e61120f924ea2cc285e8d14c3.png
[1]: https://www.baidu.com/s?tn=28114124_2_dg&wd=%E5%BA%94%E7%94%A8%E7%BA%A7%E5%88%AB%E7%9A%84%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88%E9%AB%98%E5%B9%B6%E5%8F%91#