guava ratelimiter限流(1)

骑猪看日落 2023-03-01 12:37 29阅读 0赞

本文主要介绍**互联网限流**相关的概念与**算法**，并且附以基于**guava** **ratelimiter** 的 **Java** 代码实现。包括**计数器法**、**滑动窗口计数**法、**漏斗桶算法**、**令牌桶算法**。文末实现自定义**限流注解**以及aop拦截接口实现限流。

### 文章目录 ###

*   *  限流相关的基本概念
     *   *  服务熔断
         *  服务降级
         *  服务隔离
         *  服务限流
         *  比较
     *  常见的限流手段
     *  常用的限流算法
     *   *  简单计数
         *  滑动窗口计数
         *  漏斗桶
         *  令牌桶

## 限流相关的基本概念 ##

在介绍限流之前先介绍几个容易混淆的概念。包括**服务熔断**、**服务降级**、**服务隔离**。

### 服务熔断 ###

理解**熔断**之前先了解另一个概念：**微服务**的**雪崩**效应。因为**熔断机制**通常是作为应对**雪崩效应**的一种**微服务**链路保护机制。  
  在**微服务**架构中，一个**微服务**通常是完成一个单一业务功能的独立应用。这样做的好处是各个业务功能之间最大可能地解耦，每个**微服务**可以独立演进。通常一个应用可能会有很多个**微服务**组成，服务间通过RPC相互调用。假设有如下服务调用链路：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70]  
  A,B依赖C去调用E,F。如果E服务不能正常提供服务了，C的超时重试机制将会执行。同时新的调用不断产生，会导致C对E服务的调用大量的积压，产生大量的调用等待和重试调用，慢慢会耗尽C的资源，比如内存或CPU，同时影响C调F，最终整个应用不可用。本例中由于链路上E的故障，对微服务A、B的调用就会占用越来越多的系统资源，进而引起系统崩溃，即所谓的“**雪崩效应**”。  
  **熔断机制**是应对雪崩效应的一种**微服务**链路保护机制。生活中有很多**熔断**的例子。比如电路中某个地方的电压过高，熔断器就会熔断，对电路进行过载保护。股市里面，如果股票指数涨跌幅过高，触及设置的熔断点后，随后的一段时间内将暂停交易。在微服务架构中的**熔断**机制作用类似。当调用链路的某个微服务不可用、或者响应时间太长、或者错误次数达到某个阈值，会进行服务**熔断**，即快速返回响应信息。当检测到该节点**微服务**调用响应正常后，逐步恢复正常的调用链路。

### 服务降级 ###

**服务降级**主要是指在服务器压力陡增的情况下，根据某种策略对一些非核心服务或者页面不做请求处理或简单处理，从而释放服务器资源以保证核心业务正常运作或高效运作。比如京东618活动时，把无关交易的**服务降级**，比如查看历史订单、商品历史评论等业务，只显示最近100条等等。

### 服务隔离 ###

隔离是指将服务或者资源隔离开。**服务隔离**能够在服务发生故障时限定其影响范围，保证其它服务还是可用的。资源隔离一般是指通过隔离来减少服务间资源竞争。资源隔离的粒度有很多种，比如线程隔离、进程隔离、机房隔离等。线程隔离即隔离线程池资源，不同服务的执行使用不同的线程池。这样做的好处是即使其中一个服务线程池满了，也不会影响到其他的服务。比如下图中Tomcat处理请求，对每个**微服务**，都分配一个线程池。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70 1]

### 服务限流 ###

服务**限流**是限制请求的数量，即某个时间窗口内的请求速率。一旦达到限制速率则可以拒绝服务（定向到错误页或告知系统忙）、排队等待（比如秒杀、用户评论、下单）、降级（返回兜底数据或默认数据）。

### 比较 ###

**服务熔断**、**服务降级**都是从系统的可用性角度考虑，防止系统响应延迟甚至崩溃而采用的技术性的系统保护手段。**服务熔断**一般是由某个下游服务故障引起，而**服务降级**一般是从整体业务的负载情况考虑。**限流**则是对单位时间内请求次数的限制。三者都是通过某种手段保证流量过载时系统的可用性。**服务隔离**则是让不同的业务使用各自独立的线资源池，避免服务之间资源竞争的影响。

## 常见的限流手段 ##

常见的**限流**手段有如下这些。限制总的并发数（比如数据库连接池、线程池）、限制瞬时并发数（如nginx的limit\_conn模块，用来限制瞬时并发连接数）、限制某个时间窗口内的平均速率（RateLimiter、nginx的limit\_req模块）；此外还有如限制RPC调用频率、限制MQ的消费速率等。

## 常用的限流算法 ##

### 简单计数 ###

**计数器算法**是使用计数器在周期内累加访问次数，当达到设定的阈值时，触发限流策略。下一个周期开始时，进行清零，重新计数。比如1分钟内限制请求总数为100。如果超过100则返回失败。

### 滑动窗口计数 ###

**简单计数**然简单，但是有一个致命的问题，即临界问题。比如1分钟内限制请求总数为100的场景下，前一个一分钟内直到这一分钟快结束的时候才来了100个请求，而后一个一分钟刚开始就立即来了100个请求。虽然是在两个不同的一分钟区间，但是事实上不到一分钟的时间内，来了200个请求。因此计数器限流失效。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70 2]

**滑动窗口算法**是将时间周期进一步划分为N个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期。  
  如下图，假设时间周期为1min，将1min再分为6个小周期，统计每个小周期的访问数量。如果第6个小周期内，访问数量为100，到了第7个小周期内，访问数量也为100，那么 即触发滑动窗口(红色虚线框出)内的访问次数限制。由此可见，滑动窗口的单位区间划分越多，滑动窗口的滚动就越平滑，限流统计就会越精确。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70 3]

### 漏斗桶 ###

**漏斗桶算法**顾名思义，算法内部有一个容器，类似生活中的漏斗。当请求进来时，相当于水倒入漏斗，然后从下端出水口匀速流出。不管进水速率如何变化，出水速率始终保持一致，直到漏桶为空。由于进水速度未知，突发流量来不及处理就会在桶中累积。如果突破了桶容量就会溢出，即丢弃请求。漏斗桶的示意图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70 4]

### 令牌桶 ###

**令牌桶算法**某种程度上是对**漏斗桶**算法的改进。**令牌桶**能够在限制请求平均速率的同时还允许一定程度的突发调用。在**令牌桶**算法中，存在一个桶，用来存放固定数量的令牌。该算法以一定的速率往桶中放入令牌。每次请求需要先获取到桶中的令牌才能继续执行，否则等待可用的令牌，或者直接拒绝。  
  放令牌的动作是持续不断进行的，如果桶中令牌数达到上限，则丢弃令牌，因此桶中可能一直持有大量的可用令牌。此时请求进来可以直接拿到令牌执行。比如设置qps为100，那么限流器初始化完成1秒后，桶中就已经有100个令牌了，如果此前还没有请求过来，这时突然来了100个请求，该限流器可以抵挡瞬时的100个请求。由此可见，只有桶中没有令牌时，请求才会进行等待，最终表现的效果即为以一定的速率执行。**令牌桶**的示意图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70 5]

除了在应用层限流外也可以在网络层限流，比如通过nginx的限流模块设置单个客户端IP的访问限制，本文不再赘述。  
  下一篇[《RateLimiter互联网限流实战(下)》][RateLimiter]将介绍常用的**限流算法**java实现。包括**计数器法**、**滑动窗口计数**法、**漏斗桶算法**、**令牌桶算法**，以及自定义**限流注解**以及**aop**拦截接口实现限流。

代码下载地址：[https://github.com/bigbirditedu/learn-ratelimit][https_github.com_bigbirditedu_learn-ratelimit]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70]: /images/20230208/5505d72e0f234942aef2589b2316c77d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70 1]: /images/20230208/60383f04860247fd988cffc0fe5a48d1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70 2]: /images/20230208/dfc40bb2e2924db4ae98f84af5b5be7e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70 3]: /images/20230208/333360c3061640b096436f55675a9bc9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70 4]: /images/20230208/282398bcc47e42598b5b77a832068edd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pwY2FuZHpoag_size_16_color_FFFFFF_t_70 5]: /images/20230208/f269ab994a1d4cbcac4ec38a61d48309.png
[RateLimiter]: https://blog.csdn.net/hellozpc/article/details/107582771
[https_github.com_bigbirditedu_learn-ratelimit]: https://github.com/bigbirditedu/learn-ratelimit