java限流之Guava-RateLimiter学习

       常用的限流算法有漏桶算法和令牌桶算法，guava的RateLimiter使用的是令牌桶算法，也就是以固定的频率向桶中放入令牌，例如一秒钟10枚令牌，实际业务在每次响应请求之前都从桶中获取令牌，只有取到令牌的请求才会被成功响应，获取的方式有两种：阻塞等待令牌或者取不到立即返回失败，下图来自网上：

            ratelimite原理图

实例

1、添加guava jar包

    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>18.0</version>
    </dependency>

一 有很多任务，但希望每秒不超过N个

  

package com.dukun.study.guavaTest.rateLimiterTest;

import com.google.common.util.concurrent.RateLimiter;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

/**
 *有很多个任务，但希望每秒不超过X个，可用此类
 * Created by dukun on 2019/4/23.
 */
public class Demo1 {

    public static void main(String[] args) {

        //每秒限制两个令牌 限制每秒执行几次
        RateLimiter rateLimiter = RateLimiter.create(2.0);
        List<Runnable> tasks = new ArrayList<Runnable>();
        for (int i = 0; i < 10; i++) {
            tasks.add(new UserRequest(i));
        }
        ExecutorService threadPool = Executors.newCachedThreadPool();
        for (Runnable runnable : tasks) {
            //rateLimiter.acquire()为阻塞的
            System.out.println("等待时间：" + rateLimiter.acquire());
            threadPool.execute(runnable);
        }

    }
    //处理任务
    private static class UserRequest implements Runnable {
        private int id;

        public UserRequest(int id) {
            this.id = id;
        }

        public void run() {
            System.out.println(id);
        }
    }
}

该例子是多个线程依次执行，限制每0.5秒最多执行一个。运行看结果

我们限制了0.5秒放行一个，可以看到第一个是直接执行了，后面的每0.5秒会放行一个。

rateLimiter.acquire()该方法会阻塞线程，直到令牌桶中能取到令牌为止才继续向下执行，并返回等待的时间。

二 抢购场景限流

譬如我们预估数据库能承受并发10，超过了可能会造成故障，我们就可以对该请求接口进行限流。

package com.tianyalei.controller;  
  
import com.google.common.util.concurrent.RateLimiter;  
import com.tianyalei.model.GoodInfo;  
import com.tianyalei.service.GoodInfoService;  
import org.springframework.web.bind.annotation.RequestMapping;  
import org.springframework.web.bind.annotation.RestController;  
  
import javax.annotation.Resource;  
  
/** 
 * Created by wuwf on 17/7/11. 
 */  
@RestController  
public class IndexController {  
    @Resource(name = "db")  
    private GoodInfoService goodInfoService;  
  
    RateLimiter rateLimiter = RateLimiter.create(10);  
  
    @RequestMapping("/miaosha")  
    public Object miaosha(int count, String code) {  
          //程序会阻塞在这里
          double num =   rateLimiter.acquire();
        System.out.println("等待时间" + rateLimiter.acquire());  
        //
        if (goodInfoService.update(code, count) > 0) {  
            return "购买成功";  
        }  
        return "购买失败";  
    }  
  
  
  
    @RequestMapping("/add")  
    public Object add() {  
        for (int i = 0; i < 100; i++) {  
            GoodInfo goodInfo = new GoodInfo();  
            goodInfo.setCode("iphone" + i);  
            goodInfo.setAmount(100);  
            goodInfoService.add(goodInfo);  
        }  
  
        return "添加成功";  
    }  
}  

 

代码很简单，就是请求过来时，调用RateLimiter.acquire，如果每秒超过了10个请求，就阻塞等待。我们使用jmeter进行模拟100个并发。

创建一个线程数为100，启动间隔时间为0的线程组，代表100个并发请求。

 

 

启动jmeter请求，看控制台结果

 

 

初始化10个的容量，所以前10个请求无需等待直接成功，后面的开始被1秒10次限流了，基本上每0.1秒放行一个。

   

三 抢购场景降级

上面的例子虽然限制了单位时间内对DB的操作，但是对用户是不友好的，因为他需要等待，不能迅速的得到响应。当你有1万个并发请求，一秒只能处理10个，那剩余的用户都会陷入漫长的等待。所以我们需要对应用降级，一旦判断出某些请求是得不到令牌的，就迅速返回失败，避免无谓的等待。

由于RateLimiter是属于单位时间内生成多少个令牌的方式，譬如0.1秒生成1个，那抢购就要看运气了，你刚好是在刚生成1个时进来了，那么你就能抢到，在这0.1秒内其他的请求就算白瞎了，只能寄希望于下一个0.1秒，而从用户体验上来说，不能让他在那一直阻塞等待，所以就需要迅速判断，该用户在某段时间内，还有没有机会得到令牌，这里就需要使用tryAcquire(long timeout, TimeUnit unit)方法，指定一个超时时间，一旦判断出在timeout时间内还无法取得令牌，就返回false。注意，这里并不是真正的等待了timeout时间，而是被判断为即便过了timeout时间，也无法取得令牌。这个是不需要等待的。

 

看实现：

/** 
     * tryAcquire(long timeout, TimeUnit unit) 
     * 从RateLimiter 获取许可如果该许可可以在不超过timeout的时间内获取得到的话， 
     * 或者如果无法在timeout 过期之前获取得到许可的话，那么立即返回false（无需等待） 
     */  
    @RequestMapping("/buy")  
    public Object miao(int count, String code) {  
        //判断能否在1秒内得到令牌，如果不能则立即返回false，不会阻塞程序  
        if (!rateLimiter.tryAcquire(1000, TimeUnit.MILLISECONDS)) {  
            System.out.println("短期无法获取令牌，真不幸，排队也瞎排");  
            return "失败";  
        }  
        if (goodInfoService.update(code, count) > 0) {  
            System.out.println("购买成功");  
            return "成功";  
        }  
        System.out.println("数据不足，失败");  
        return "失败";  
    }

在不看执行结果的情况下，我们可以先分析一下，一秒出10个令牌，0.1秒出一个，100个请求进来，假如100个是同时到达，那么最终只能成交10个，90个都会因为超时而失败。事实上，并不会完全同时到达，必然会出现在0.1秒后到达的，就会被归入下一个周期。这是一个挺复杂的数学问题，每一个请求都会被计算未来可能获取到令牌的概率。

还好，RateLimiter有自己的方法去做判断。

我们运行看结果

 

多执行几次，发现每次这个顺序都不太一样。

经过我多次试验，当设置线程组的间隔时间为0时，最终购买成功的数量总是22.其他的78个都是失败。但基本都是开始和结束时连续成功，中间的大段失败。

我修改一下jmeter线程组这100个请求的产生时间为1秒时，结果如下

 

除了前面几个和最后几个请求连续成功，中间的就比较稳定了，都是隔8个9个就会成功一次。

 

当我修改为2秒内产生100个请求时，结果就更平均了

 

基本上就是前10个成功，后面的就开始按照固定的速率而成功了。

这种场景更符合实际的应用场景，按照固定的单位时间进行分割，每个单位时间产生一个令牌，可供购买。

看到这里是不是有点明白抢小米的情况了，很多时候并不是你网速快，手速快就能抢到，你需要看后台系统的分配情况。所以你能否抢到，最好是开很多个账号，而不是一直用一个账号在猛点，因为你点也白点，后台已经把你的资格排除在外了。

当然了，真正的抢购不是这么简单，瞬间的流量洪峰会冲垮服务器的负载，当100万人抢1万个小米时，连接口都请求不进来，更别提接口里的令牌分配了。

此时就需要做上一层的限流，我们可以选择在上一层做分布式，开多个服务，先做一次限流，淘汰掉绝大多数运气不好的用户，甚至可以随机丢弃某些规则的用户，迅速拦截90%的请求，让你去网页看单机排队动画，还剩10万。10万也太大，足以冲垮数据层，那就进队列MQ，用MQ削峰后，然后才放进业务逻辑里，再进行RateLimiter的限流，此时又能拦截掉90%的不幸者，还剩1万，1万去交给业务逻辑和数据层，用redis和DB来处理库存。恭喜，你就是那个漏网之鱼。

重点在于迅速拦截掉99%的不幸者，避免让他们去接触到数据层。而且不能等待时间太长，最好是请求的瞬间就能确定你是永远看单机动画最好。

 

RateLimiter方法摘要

修饰符和类型	方法和描述
double	acquire() 从RateLimiter获取一个许可，该方法会被阻塞直到获取到请求
double	acquire(int permits)从RateLimiter获取指定许可数，该方法会被阻塞直到获取到请求
static RateLimiter	create(double permitsPerSecond)根据指定的稳定吞吐率创建RateLimiter，这里的吞吐率是指每秒多少许可数（通常是指QPS，每秒多少查询）
static RateLimiter	create(double permitsPerSecond, long warmupPeriod, TimeUnit unit)根据指定的稳定吞吐率和预热期来创建RateLimiter，这里的吞吐率是指每秒多少许可数（通常是指QPS，每秒多少个请求量），在这段预热时间内，RateLimiter每秒分配的许可数会平稳地增长直到预热期结束时达到其最大速率。（只要存在足够请求数来使其饱和）
double	getRate()返回RateLimiter 配置中的稳定速率，该速率单位是每秒多少许可数
void	setRate(double permitsPerSecond)更新RateLimite的稳定速率，参数permitsPerSecond 由构造RateLimiter的工厂方法提供。
String	toString()返回对象的字符表现形式
boolean	tryAcquire()从RateLimiter 获取许可，如果该许可可以在无延迟下的情况下立即获取得到的话
boolean	tryAcquire(int permits)从RateLimiter 获取许可数，如果该许可数可以在无延迟下的情况下立即获取得到的话
boolean	tryAcquire(int permits, long timeout, TimeUnit unit)从RateLimiter 获取指定许可数如果该许可数可以在不超过timeout的时间内获取得到的话，或者如果无法在timeout 过期之前获取得到许可数的话，那么立即返回false （无需等待）
boolean	tryAcquire(long timeout, TimeUnit unit)从RateLimiter 获取许可如果该许可可以在不超过timeout的时间内获取得到的话，或者如果无法在timeout 过期之前获取得到许可的话，那么立即返回false（无需等待）

RateLimiter注意点

RateLimiter 有一个有趣的特性是「前人挖坑后人跳」，也就是说 RateLimiter 允许某次请求拿走超出剩余令牌数的令牌，但是下一次请求将为此付出代价，一直等到令牌亏空补上，并且桶中有足够本次请求使用的令牌为止。这里面就涉及到一个权衡，是让前一次请求干等到令牌够用才走掉呢，还是让它先走掉后面的请求等一等呢？Guava 的设计者选择的是后者，先把眼前的活干了，后面的事后面再说。

测试代码：

public class RateLimiterMain {
    public static void main(String[] args) {
        RateLimiter rateLimiter = RateLimiter.create(2);
        System.out.println(rateLimiter.acquire(5));
        System.out.println(rateLimiter.acquire(2));
        System.out.println(rateLimiter.acquire(1));
    }
}

输出内容：

0.0
2.496889
0.992149

可以看出，令牌桶每秒只能产生2个令牌，我们可以第一次取出5个，但是第二个再去取令牌的时候，需要等2.5s，也就是第一次令牌取完后，需要等2.5s才能取到令牌。同样的，第三次取1个令牌的时候，也需要等待第二次的1s的时间。也就是，取的速率可以超过令牌产生的速率，但是下一次再次去取的时候，需要阻塞等待。

当然也可以使用tryAcquire来非阻塞的获取，可以实时返回结果。另外tryAcquire也可以传入参数，也就是等待的时间，超时直接返回false。这点等同于常见的lock，tryLock。