guava ratelimiter限流(1)

【订阅专栏合集，关注公众号，作者所有付费文章都能看(持续更新)】

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

限流相关的基本概念

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

服务熔断

  理解熔断之前先了解另一个概念：微服务的雪崩效应。因为熔断机制通常是作为应对雪崩效应的一种微服务链路保护机制。
  在微服务架构中，一个微服务通常是完成一个单一业务功能的独立应用。这样做的好处是各个业务功能之间最大可能地解耦，每个微服务可以独立演进。通常一个应用可能会有很多个微服务组成，服务间通过RPC相互调用。假设有如下服务调用链路：

  A,B依赖C去调用E,F。如果E服务不能正常提供服务了，C的超时重试机制将会执行。同时新的调用不断产生，会导致C对E服务的调用大量的积压，产生大量的调用等待和重试调用，慢慢会耗尽C的资源，比如内存或CPU，同时影响C调F，最终整个应用不可用。本例中由于链路上E的故障，对微服务A、B的调用就会占用越来越多的系统资源，进而引起系统崩溃，即所谓的“雪崩效应”。
  熔断机制是应对雪崩效应的一种微服务链路保护机制。生活中有很多熔断的例子。比如电路中某个地方的电压过高，熔断器就会熔断，对电路进行过载保护。股市里面，如果股票指数涨跌幅过高，触及设置的熔断点后，随后的一段时间内将暂停交易。在微服务架构中的熔断机制作用类似。当调用链路的某个微服务不可用、或者响应时间太长、或者错误次数达到某个阈值，会进行服务熔断，即快速返回响应信息。当检测到该节点微服务调用响应正常后，逐步恢复正常的调用链路。

服务降级

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

服务隔离

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

服务限流

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

比较

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

常见的限流手段

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

常用的限流算法

简单计数

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

滑动窗口计数

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

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

漏斗桶

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

令牌桶

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

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

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