流量控制：高并发系统中我们如何操纵流量？

傷城~ 2024-02-20 09:36 58阅读 0赞

**目录**

前言

一、究竟什么是限流？

二、你应该知道的限流算法

1.计数器法（固定窗口）

2.滑动窗口算法

3.漏斗算法

4.令牌桶算法

三、Hystrix服务限流（服务隔离）

1、线程池隔离模式

2、信号量隔离模式

四、总结

参考

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

## 前言 ##

随着现在微服务、分布式系统的发展，各个服务之间的相互调用越来越复杂。

为了保证自身服务的稳定性与高可用，当面对超过自身服务能力的请求调用时，要做一定的限流措施。

如同五一、国庆期间的旅游出行、景区爆满，游客限流。我们的服务面对诸如秒杀、大促、618、双十一以及可能的恶意攻击、爬虫等高并发、大流量的场景也需要做服务限流。

**概念**：对超出服务处理能力之外的请求进行拦截，对访问服务的流量进行限制。

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

## **一、****究竟什么是限流****？** ##

限流指的是通过限制到达系统的并发请求数量，保证系统能够正常响应部分用户请求，而对于超过限制的流量，则只能通过拒绝服务的方式保证整体系统的可用性。限流策略一般部署在服务的入口层，比如 API 网关中，这样可以对系统整体流量做塑形。而在微服务架构中，你也可以在 RPC 客户端中引入限流的策略，来保证单个服务不会被过大的流量压垮。

其实，无论在实际工作生活中还是在之前学习过的知识中，你都可能对限流策略有过应用，我给你举个例子。

如果你挤过地铁，就更能感同身受了。北京早高峰的地铁都会限流，想法很直接，就是控制进入地铁的人数，保证地铁不会被挤爆，也可以尽量保障人们的安全。

而无论是在一体化架构还是微服务化架构中，我们也可以在多个维度上对到达系统的流量做控制，比如：

*  你可以对系统每分钟处理多少请求做限制；
 *  可以针对单个接口设置每分钟请求流量的限制；
 *  可以限制单个 IP、用户 ID 或者设备 ID 在一段时间内发送请求的数量
 *  对于服务于多个第三方应用的开放平台来说，每一个第三方应用对于平台方来说都有一个唯一的 appkey 来标识，那么你也可以限制单个 appkey 的访问接口的速率。

而实现上述限制速率的方式是基于一些限流算法的，那么常见的限流的算法有哪些呢？你在实现限流的时候都有哪些方式呢？

## 二、**你应该知道的限流算法**  ##

### 1.计数器法（固定窗口） ###

**概念** ：在单位时间内，统计进入的请求数量，统计值达到限流阈值时，开始限流（如拒绝和排队）。这个单位时间结束后，计算器清零，重新开始计数。

问题：在固定时间窗口切换处，最高可能会接收到2倍阈值的流量。

> 假如设置的时间窗口为5秒，限流阈值为10.
> 
> 第5秒时进来10个流量，此时窗口内流量未超阈值。第6秒切换到下一个窗口，此时进来流量10，当前窗口流量仍未超阈值。但是 第5秒和第6秒的切换临界处，短时间内进来了限流阈值的双倍流量，此时服务可能会因为请求流量过多而发生异常。

固定窗口

![acbb5cd6154f41fda10586e580baf763.png][]

### 2.滑动窗口算法 ###

**概念**： 滑动窗口对固定窗口进行改良，将其细化，将一个时间窗口划分为若干个时间窗格，每个窗格代表固定的时间段（如1分钟）、拥有独立的计数器，每过固定时间（如1分钟），将滑动窗口向前移动一格。滑动窗口中的窗格划分越细，限流统计越精确。

> 假如设置的时间窗口为5秒，限流阈值为10.
> 
> 第5秒时进来10个流量，此时窗口内流量未超阈值。第6秒时进来流量10,与此同时，滑动窗口右移一格，此时滑动窗口内（第2~6秒）流量为20，大于限流阈值，开始限流。

![8764205b714d4b47a14ddd9b99b8fdde.png][]

### 3.漏斗算法 ###

> **漏桶算法的原理很简单，它就像在流量产生端和接收端之间增加一个漏桶，流量会进入和暂存到漏桶里面，而漏桶的出口处会按照一个固定的速率将流量漏出到接收端（也就是服务接口）。**
> 
> **如果流入的流量在某一段时间内大增，超过了漏桶的承受极限，那么多余的流量就会触发限流策略，被拒绝服务。**

`漏斗算法可以平滑流量，但是无法解决流量突增的问题。`

![537db259ff664258a6178dd234e15d8b.png][]

### 4.令牌桶算法 ###

> **概念**：以恒定速率（`令牌产生速率`）向令牌桶中放入令牌，令牌桶满（`令牌桶大小`）则无法放入。请求到达后先获取令牌，拿到令牌后请求被处理并删除获得的令牌。令牌不足时，请求无法获得令牌，请求被拒绝。

`令牌桶算法可以平滑限流，同时可以容忍突发流量。`

![3a50b6a453fb40b6b7a1b0b7ae40a5ba.png][]

如果要从算法中做选择，我更倾向于使用令牌桶算法，原因是漏桶算法在面对突发流量的时候，采用的解决方式是缓存在漏桶中， 这样流量的响应时间就会增长，这就与互联网业务低延迟的要求不符；而令牌桶算法可以在令牌中暂存一定量的令牌，能够应对一定的突发流量，所以一般我会使用令牌桶算法来实现限流方案，而 Guava 中的限流方案就是使用令牌桶算法来实现的。

你可以看到，使用令牌桶算法就需要存储令牌的数量，如果是单机上实现限流的话，可以在进程中使用一个变量来存储；但是如果在分布式环境下，不同的机器之间无法共享进程中的变量，我们就一般会使用 Redis 来存储这个令牌的数量。这样的话，每次请求的时候都需要请求一次 Redis 来获取一个令牌，会增加几毫秒的延迟，性能上会有一些损耗。因此，一个折中的思路是： 我们可以在每次取令牌的时候，不再只获取一个令牌，而是获取一批令牌，这样可以尽量减少请求 Redis 的次数。

## 三、Hystrix服务限流（服务隔离） ##

通过线程池或者信号量判断是否已满，超出容量的请求直接降级，以达到限流的作用。在springcloud架构的系统中，可以在网关启用Hystrix，进行限流处理，每个微服务也可以各自启用Hystrix进行限流。

**两种资源隔离模式**：`线程池隔离模式`、`信号量隔离模式`

### 1、线程池隔离模式 ###

使用一个线程池来存储当前的请求，线程池对请求作处理，设置任务返回处理超时时间，堆积的请求入线程池队列。这种方式需要为每个依赖的服务申请线程池，有一定的资源消耗，好处是可以应对突发流量（流量洪峰来临时，处理不完可将数据存储到线程池队列里慢慢处理）。

> //线程池隔离的设置  
> @HystrixCommand(  
> groupKey=“test-provider”,  
> threadPoolKey=“test-provider”,  
> threadPoolProperties = \{  
> @HystrixProperty(name = “coreSize”, value = “20”),//线程池大小  
> @HystrixProperty(name = “maximumSize”, value = “30”),//最大线程池大小  
> @HystrixProperty(name = “maxQueueSize”, value = “20”),//最大队列长度  
> @HystrixProperty(name = “keepAliveTimeMinutes”, value = “2”)//线程存活时间  
> \},commandProperties = \{  
> @HystrixProperty(name = “execution.isolation.strategy”,value = “THREAD”)  
> \}

### 2、信号量隔离模式 ###

使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，请求来先判断计数器的数值，若超过设置的最大线程个数则丢弃改类型的新请求，若不超过则执行计数操作请求计数器+1，请求返回计数器-1。这种方式是严格的控制线程且立即返回模式，无法应对突发流量（流量洪峰来临时，处理的线程超过数量，其他的请求会直接返回，不继续去请求依赖的服务）。

> //信号量隔离的设置  
> @HystrixCommand(  
> //用来设置降级方法  
> fallbackMethod = “myTestFallbackMethod”,  
> commandProperties = \{  
> //进行熔断配置  
> //条件1，设置在滚动时间窗口中，断路器的最小请求数（没有达到不会熔断）。默认20。  
> @HystrixProperty(name = “circuitBreaker.requestVolumeThreshold” ,value = “10”),  
> //条件2，设置断路器打开的错误百分比。在滚动时间内，在请求数量超过requestVolumeThreshold的值,且错误请求数的百分比超过这个比例，断路器就为打开状态。  
> @HystrixProperty(name = “circuitBreaker.errorThresholdPercentage” ,value = “30”),  
> //条件3，设置滚动时间窗的长度，单位毫秒。这个时间窗口就是断路器收集信息的持续时间。断路器在收集指标信息的时会根据这个时间窗口把这个窗口拆分成多个桶，每个桶代表一段时间的指标，默认10000.  
> @HystrixProperty(name = “metrics.rollingStats.timeInMilliseconds” ,value = “10000”),  
> //设置当断路器打开之后的休眠时间，休眠时间结束后断路器为半开状态，断路器能接受请求，如果请求失败又重新回到打开状态，如果请求成功又回到关闭状态  
> //单位是毫秒  
> @HystrixProperty(name = “circuitBreaker.sleepWindowInMilliseconds” ,value = “3000”),  
> //配置信号量隔离  
> //配置信号量的数值  
> @HystrixProperty(name = “execution.isolation.semaphore.maxConcurrentRequests”,value = “100”),  
> //选择策略为信号量隔离  
> @HystrixProperty(name = “execution.isolation.strategy”, value = “SEMAPHORE”),  
> //设置HystrixCommand执行的超时时间，单位毫秒  
> @HystrixProperty(name = “execution.isolation.thread.timeoutInMilliseconds”, value = “1000000000”)  
> \}  
> )

线程池隔离与信号量隔离的最大区别在于发送请求的线程，信号量是采用调用方法的线程，而线程池则是用池内的线程去发送请求

## 四、**总结** ##

限流策略是微服务治理中的标配策略，只是你很难在实际中确认限流的阈值是多少，设置的小了容易误伤正常的请求，设置的大了则达不到限流的目的。所以，一般在实际项目中，我们会把阈值放置在配置中心中方便动态调整；同时，我们可以通过定期地压力测试得到整体系统以及每个微服务的实际承载能力，然后再依据这个压测出来的值设置合适的阈值。

### 参考 ###

[springcloud-服务熔断\_springcloud 熔断-CSDN博客][springcloud-_springcloud _-CSDN]

[acbb5cd6154f41fda10586e580baf763.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/3f976a7c6bc14e6f84b7a01912674a72.png
[8764205b714d4b47a14ddd9b99b8fdde.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/5de67eb5aa144b54882e015c9db4121c.png
[537db259ff664258a6178dd234e15d8b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/11f1040c8ede4e83a5de416354b0990b.png
[3a50b6a453fb40b6b7a1b0b7ae40a5ba.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/c94d3ef609af40c39e0b9b2a49112db0.png
[springcloud-_springcloud _-CSDN]: https://blog.csdn.net/paiidds/article/details/124906993