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个并发请求。
三 抢购场景降级
上面的例子虽然限制了单位时间内对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秒时，结果如下