使用RateLimiter完成简单的大流量限流，抢购秒杀限流

RateLimiter是guava提供的基于令牌桶算法的实现类，能够很是简单的完成限流特技，而且根据系统的实际状况来调整生成token的速率。

一般可应用于抢购限流防止冲垮系统；限制某接口、服务单位时间内的访问量，譬如一些第三方服务会对用户访问量进行限制；限制网速，单位时间内只容许上传下载多少字节等。

下面来看一些简单的实践，须要先引入guava的maven依赖。

一 有不少任务，但但愿每秒不超过N个

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;  
  
/** 
 * Created by wuwf on 17/7/11. 
 * 有不少个任务，但但愿每秒不超过X个，可用此类 
 */  
public class Demo1 {  
  
    public static void main(String[] args) {  
        //0.5表明一秒最多多少个  
        RateLimiter rateLimiter = RateLimiter.create(0.5);  
        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) {  
            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);  
        }  
    }  
  
}  

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

咱们限制了2秒放行一个，能够看到第一个是直接执行了，后面的每2秒会放行一个。

 

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) {  
        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 "添加成功";  
    }  
}  

这个是接着以前的文章（秒杀系统db，http://blog.csdn.net/tianyaleixiaowu/article/details/74389273）加了个Controller

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

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

 

初始化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，只用db的Service处理数据的状况，发现mysql的服务占CPU约20%，整体请求失败率较高。可能是Tomcat超时。

使用RateLimiter阻塞后，数据库CPU基本没动静，压力几乎没有，Tomcat超时还有一些，由于仍是并发数大，处理不了。

使用RateLimiter非阻塞，超时和请求失败极少，整体QPS上升了很多。