使用Guava RateLimiter限流入门到深入

痛定思痛。 2022-11-21 04:12 222阅读 0赞

## 前言 ##

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流

*  `缓存`: 缓存的目的是提升系统访问速度和增大系统处理容量
 *  `降级`: 降级是当服务出现问题或者影响到核心流程时，需要暂时屏蔽掉，待高峰或者问题解决后再打开
 *  `限流`: 限流的目的是通过对并发访问/请求进行限速，或者对一个时间窗口内的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理

## 常见限流算法 ##

1.  **漏桶算法**

漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。

![d153fb5a7434d0d0e43e79be4658a62b.png][]

1.  **令牌桶算法**

对于很多应用场景来说，除了要求能够限制数据的平均传输速率外，还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。如图所示，令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。

![37e3f248e86920c4e7863bbf71f5e778.png][]

## RateLimiter使用以及源码解析 ##

Google开源工具包Guava提供了限流工具类RateLimiter，该类基于令牌桶算法实现流量限制，使用十分方便，而且十分高效。

### RateLimiter使用 ###

首先简单介绍下RateLimiter的使用

public void testAcquire() { 
          RateLimiter limiter = RateLimiter.create(1);
          for(int i = 1; i < 10; i = i + 2 ) { 
              double waitTime = limiter.acquire(i);
              System.out.println("cutTime=" + System.currentTimeMillis() + " acq:" + i + " waitTime:" + waitTime);
          }
      }

输出结果：

cutTime=1535439657427 acq:1 waitTime:0.0
    cutTime=1535439658431 acq:3 waitTime:0.997045
    cutTime=1535439661429 acq:5 waitTime:2.993028
    cutTime=1535439666426 acq:7 waitTime:4.995625
    cutTime=1535439673426 acq:9 waitTime:6.999223

首先通过`RateLimiter.create(1)`创建一个限流器，参数代表每秒生成的令牌数，通过`limiter.acquire(i)`来以阻塞的方式获取令牌，当然也可以通过`tryAcquire(int permits, long timeout, TimeUnit unit)`来设置等待超时时间的方式获取令牌，如果超timeout为0，则代表非阻塞，获取不到立即返回。

从输出来看，RateLimiter支持预消费，比如在acquire(5)时，等待时间是3秒，是上一个获取令牌时预消费了3个两排，固需要等待3\*1秒，然后又预消费了5个令牌，以此类推

**RateLimiter通过限制后面请求的等待时间，来支持一定程度的突发请求(预消费)**，在使用过程中需要注意这一点，具体实现原理后面再分析。

### RateLimiter实现原理 ###

Guava有两种限流模式，一种为稳定模式(SmoothBursty:令牌生成速度恒定)，一种为渐进模式(SmoothWarmingUp:令牌生成速度缓慢提升直到维持在一个稳定值) 两种模式实现思路类似，主要区别在等待时间的计算上，本篇重点介绍SmoothBursty

#### RateLimiter的创建 ####

通过调用RateLimiter的create接口来创建实例，实际是调用的SmoothBuisty稳定模式创建的实例。

public static RateLimiter create(double permitsPerSecond) { 
        return create(permitsPerSecond, SleepingStopwatch.createFromSystemTimer());
      }
    
      static RateLimiter create(double permitsPerSecond, SleepingStopwatch stopwatch) { 
        RateLimiter rateLimiter = new SmoothBursty(stopwatch, 1.0 /* maxBurstSeconds */);
        rateLimiter.setRate(permitsPerSecond);
        return rateLimiter;
      }

`SmoothBursty`中的两个构造参数含义：

*  SleepingStopwatch：guava中的一个时钟类实例，会通过这个来计算时间及令牌
 *  maxBurstSeconds：官方解释，在ReteLimiter未使用时，最多保存几秒的令牌，默认是1

在解析SmoothBursty原理前，重点解释下SmoothBursty中几个属性的含义

/** * The work (permits) of how many seconds can be saved up if this RateLimiter is unused? * 在RateLimiter未使用时，最多存储几秒的令牌 * */
     final double maxBurstSeconds;
     
    
    /** * The currently stored permits. * 当前存储令牌数 */
    double storedPermits;
    
    /** * The maximum number of stored permits. * 最大存储令牌数 = maxBurstSeconds * stableIntervalMicros(见下文) */
    double maxPermits;
    
    /** * The interval between two unit requests, at our stable rate. E.g., a stable rate of 5 permits * per second has a stable interval of 200ms. * 添加令牌时间间隔 = SECONDS.toMicros(1L) / permitsPerSecond；(1秒/每秒的令牌数) */
    double stableIntervalMicros;
    
    /** * The time when the next request (no matter its size) will be granted. After granting a request, * this is pushed further in the future. Large requests push this further than small requests. * 下一次请求可以获取令牌的起始时间 * 由于RateLimiter允许预消费，上次请求预消费令牌后 * 下次请求需要等待相应的时间到nextFreeTicketMicros时刻才可以获取令牌 */
    private long nextFreeTicketMicros = 0L; // could be either in the past or future

接下来介绍几个关键函数

*  setRate

public final void setRate(double permitsPerSecond) { 
      checkArgument(
          permitsPerSecond > 0.0 && !Double.isNaN(permitsPerSecond), "rate must be positive");
      synchronized (mutex()) { 
        doSetRate(permitsPerSecond, stopwatch.readMicros());
      }
    }

通过这个接口设置令牌通每秒生成令牌的数量，内部时间通过调用SmoothRateLimiter的doSetRate来实现

*  doSetRate

@Override
      final void doSetRate(double permitsPerSecond, long nowMicros) { 
        resync(nowMicros);
        double stableIntervalMicros = SECONDS.toMicros(1L) / permitsPerSecond;
        this.stableIntervalMicros = stableIntervalMicros;
        doSetRate(permitsPerSecond, stableIntervalMicros);
      }

这里先通过调用resync生成令牌以及更新下一期令牌生成时间，然后更新stableIntervalMicros，最后又调用了SmoothBursty的doSetRate

*  resync

/** * Updates {@code storedPermits} and {@code nextFreeTicketMicros} based on the current time. * 基于当前时间，更新下一次请求令牌的时间，以及当前存储的令牌(可以理解为生成令牌) */
    void resync(long nowMicros) { 
        // if nextFreeTicket is in the past, resync to now
        if (nowMicros > nextFreeTicketMicros) { 
          double newPermits = (nowMicros - nextFreeTicketMicros) / coolDownIntervalMicros();
          storedPermits = min(maxPermits, storedPermits + newPermits);
          nextFreeTicketMicros = nowMicros;
        }
    }

根据令牌桶算法，桶中的令牌是持续生成存放的，有请求时需要先从桶中拿到令牌才能开始执行，谁来持续生成令牌存放呢？

一种解法是，开启一个定时任务，由定时任务持续生成令牌。这样的问题在于会极大的消耗系统资源，如，某接口需要分别对每个用户做访问频率限制，假设系统中存在6W用户，则至多需要开启6W个定时任务来维持每个桶中的令牌数，这样的开销是巨大的。

另一种解法则是延迟计算，如上resync函数。该函数会在每次获取令牌之前调用，其实现思路为，若当前时间晚于nextFreeTicketMicros，则计算该段时间内可以生成多少令牌，将生成的令牌加入令牌桶中并更新数据。这样一来，只需要在获取令牌时计算一次即可。

*  SmoothBursty的doSetRate

@Override
    void doSetRate(double permitsPerSecond, double stableIntervalMicros) { 
      double oldMaxPermits = this.maxPermits;
      maxPermits = maxBurstSeconds * permitsPerSecond;
      if (oldMaxPermits == Double.POSITIVE_INFINITY) { 
        // if we don't special-case this, we would get storedPermits == NaN, below
        // Double.POSITIVE_INFINITY 代表无穷啊
        storedPermits = maxPermits;
      } else { 
        storedPermits =
            (oldMaxPermits == 0.0)
                ? 0.0 // initial state
                : storedPermits * maxPermits / oldMaxPermits;
      }
    }

桶中可存放的最大令牌数由maxBurstSeconds计算而来，其含义为最大存储maxBurstSeconds秒生成的令牌。  
该参数的作用在于，可以更为灵活地控制流量。如，某些接口限制为300次/20秒，某些接口限制为50次/45秒等。也就是流量不局限于qps

## 参考 ##

*  [使用Guava RateLimiter限流以及源码解析][Guava RateLimiter]
 *  [使用Guava的RateLimiter做限流 ][Guava_RateLimiter_]
 *  [SpringBoot使用RateLimiter通过AOP方式进行限流][SpringBoot_RateLimiter_AOP]
 *  [Guava RateLimiter源码解析][Guava RateLimiter 1]

## 结语 ##

欢迎关注微信公众号『码仔zonE』，专注于分享Java、云计算相关内容，包括SpringBoot、SpringCloud、微服务、Docker、Kubernetes、Python等领域相关技术干货，期待与您相遇！  
![1a98fed2d84c46b7b68cc6b0b0ee84a6.png][]

[d153fb5a7434d0d0e43e79be4658a62b.png]: /images/20221120/9fc767e16e814e60b02e11080463c9b3.png
[37e3f248e86920c4e7863bbf71f5e778.png]: /images/20221120/24c598e1d3514c1a97e2e4adafb999a6.png
[Guava RateLimiter]: https://www.jianshu.com/p/5d4fe4b2a726
[Guava_RateLimiter_]: https://my.oschina.net/hanchao/blog/1833612?appinstall=0
[SpringBoot_RateLimiter_AOP]: https://blog.csdn.net/u014769528/article/details/84526363
[Guava RateLimiter 1]: https://segmentfault.com/a/1190000012875897
[1a98fed2d84c46b7b68cc6b0b0ee84a6.png]: /images/20221120/ebd29828c2fc40649108a528df800ebf.png