工作中对外提供的API 接口设计都要考虑限流，如果不考虑限流，会成系统的连锁反应，轻者响应缓慢，重者系统宕机，整个业务线崩溃，如何应对这种情况呢，我们可以对请求进行引流或者直接拒绝等操作，保持系统的可用性和稳定性，防止因流量暴增而导致的系统运行缓慢或宕机。
在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流
缓存：缓存的目的是提升系统访问速度和增大系统处理容量
降级：降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行
限流：限流的目的是通过对并发访问/请求进行限速，或者对一个时间窗口内的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理
限流算法
常用的限流算法有令牌桶和和漏桶，而Google开源项目Guava中的RateLimiter使用的就是令牌桶控制算法。
漏桶算法
把请求比作是水，水来了都先放进桶里，并以限定的速度出水，当水来得过猛而出水不够快时就会导致水直接溢出，即拒绝服务。
漏斗有一个进水口 和 一个出水口，出水口以一定速率出水，并且有一个最大出水速率：
在漏斗中没有水的时候，
- 如果进水速率小于等于最大出水速率，那么，出水速率等于进水速率，此时，不会积水
- 如果进水速率大于最大出水速率，那么，漏斗以最大速率出水，此时，多余的水会积在漏斗中
在漏斗中有水的时候
- 出水口以最大速率出水
- 如果漏斗未满，且有进水的话，那么这些水会积在漏斗中
- 如果漏斗已满，且有进水的话，那么这些水会溢出到漏斗之外
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
/**
* 漏斗限流算法
*
* @author dadiyang
* @date 2018/9/28
*/
public class FunnelRateLimiter {
private Map<String, Funnel> funnelMap = new ConcurrentHashMap<>();
public static void main(String[] args) throws InterruptedException {
FunnelRateLimiter limiter = new FunnelRateLimiter();
int testAccessCount = 30;
int capacity = 5;
int allowQuota = 5;
int perSecond = 30;
int allowCount = 0;
int denyCount = 0;
for (int i = 0; i < testAccessCount; i++) {
boolean isAllow = limiter.isActionAllowed("dadiyang", "doSomething", 5, 5, 30);
if (isAllow) {
allowCount++;
} else {
denyCount++;
}
System.out.println("访问权限：" + isAllow);
Thread.sleep(1000);
}
System.out.println("报告：");
System.out.println("漏斗容量：" + capacity);
System.out.println("漏斗流动速率：" + allowQuota + "次/" + perSecond + "秒");
System.out.println("测试次数=" + testAccessCount);
System.out.println("允许次数=" + allowCount);
System.out.println("拒绝次数=" + denyCount);
}
/**
* 根据给定的漏斗参数检查是否允许访问
*
* @param username 用户名
* @param action 操作
* @param capacity 漏斗容量
* @param allowQuota 每单个单位时间允许的流量
* @param perSecond 单位时间（秒）
* @return 是否允许访问
*/
public boolean isActionAllowed(String username, String action, int capacity, int allowQuota, int perSecond) {
String key = "funnel:" + action + ":" + username;
if (!funnelMap.containsKey(key)) {
funnelMap.put(key, new Funnel(capacity, allowQuota, perSecond));
}
Funnel funnel = funnelMap.get(key);
return funnel.watering(1);
}
private static class Funnel {
private int capacity;
private float leakingRate;
private int leftQuota;
private long leakingTs;
public Funnel(int capacity, int count, int perSecond) {
this.capacity = capacity;
// 因为计算使用毫秒为单位的
perSecond *= 1000;
this.leakingRate = (float) count / perSecond;
}
/**
* 根据上次水流动的时间，腾出已流出的空间
*/
private void makeSpace() {
long now = System.currentTimeMillis();
long time = now - leakingTs;
int leaked = (int) (time * leakingRate);
if (leaked < 1) {
return;
}
leftQuota += leaked;
// 如果剩余大于容量，则剩余等于容量
if (leftQuota > capacity) {
leftQuota = capacity;
}
leakingTs = now;
}
/**
* 漏斗漏水
*
* @param quota 流量
* @return 是否有足够的水可以流出（是否允许访问）
*/
public boolean watering(int quota) {
makeSpace();
int left = leftQuota - quota;
if (left >= 0) {
leftQuota = left;
return true;
}
return false;
}
}
}令牌桶算法
对于很多应用场景来说，除了要求能够限制数据的平均传输速率外，还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。
令牌桶算法的原理是系统以恒定的速率产生令牌，然后把令牌放到令牌桶中，令牌桶有一个容量，当令牌桶满了的时候，再向其中放令牌，那么多余的令牌会被丢弃；当想要处理一个请求的时候，需要从令牌桶中取出一个令牌，如果此时令牌桶中没有令牌，那么则拒绝该请求。
RateLimiter 用法
https://github.com/google/guava
添加依赖
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>26.0-jre</version>
<!-- or, for Android: -->
<version>26.0-android</version>
</dependency>public class Test {
public static void main(String[] args) {
ListeningExecutorService executorService = MoreExecutors.listeningDecorator(Executors.newFixedThreadPool(100));
// 指定每秒放1个令牌
RateLimiter limiter = RateLimiter.create(1);
for (int i = 1; i < 50; i++) {
// 请求RateLimiter, 超过permits会被阻塞
//acquire(int permits)函数主要用于获取permits个令牌，并计算需要等待多长时间，进而挂起等待，并将该值返回
Double acquire = null;
if (i == 1) {
acquire = limiter.acquire(1);
} else if (i == 2) {
acquire = limiter.acquire(10);
} else if (i == 3) {
acquire = limiter.acquire(2);
} else if (i == 4) {
acquire = limiter.acquire(20);
} else {
acquire = limiter.acquire(2);
}
executorService.submit(new Task("获取令牌成功，获取耗：" + acquire + " 第 " + i + " 个任务执行"));
}
}
}
class Task implements Runnable {
String str;
public Task(String str) {
this.str = str;
}
@Override
public void run() {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");
System.out.println(sdf.format(new Date()) + " | " + Thread.currentThread().getName() + str);
}
}响应
2018-08-11 00:26:22.953 | pool-1-thread-1获取令牌成功，获取耗：0.0 第 1 个任务执行
2018-08-11 00:26:23.923 | pool-1-thread-2获取令牌成功，获取耗：0.98925 第 2 个任务执行
2018-08-11 00:26:33.920 | pool-1-thread-3获取令牌成功，获取耗：9.996993 第 3 个任务执行
2018-08-11 00:26:35.920 | pool-1-thread-4获取令牌成功，获取耗：1.999051 第 4 个任务执行
2018-08-11 00:26:55.920 | pool-1-thread-5获取令牌成功，获取耗：19.999726 第 5 个任务执行
2018-08-11 00:26:57.920 | pool-1-thread-6获取令牌成功，获取耗：1.999139 第 6 个任务执行
2018-08-11 00:26:59.920 | pool-1-thread-7获取令牌成功，获取耗：1.999806 第 7 个任务执行
2018-08-11 00:27:01.919 | pool-1-thread-8获取令牌成功，获取耗：1.999433 第 8 个任务执行acquire函数主要用于获取permits个令牌，并计算需要等待多长时间，进而挂起等待，并将该值返回
一个RateLimiter主要定义了发放permits的速率。如果没有额外的配置，permits将以固定的速度分配，单位是每秒多少permits。默认情况下，Permits将会被稳定的平缓的发放。
预消费能力
从输出结果可以看出，指定每秒放1个令牌，RateLimiter具有预消费的能力：
acquire 1 时，并没有任何等待 0.0 秒 直接预消费了1个令牌acquire 10时，由于之前预消费了 1 个令牌，故而等待了1秒，之后又预消费了10个令牌acquire 2 时，由于之前预消费了 10 个令牌，故而等待了10秒，之后又预消费了2个令牌acquire 20 时，由于之前预消费了 2 个令牌，故而等待了2秒，之后又预消费了20个令牌acquire 2 时，由于之前预消费了 20 个令牌，故而等待了20秒，之后又预消费了2个令牌acquire 2 时，由于之前预消费了 2 个令牌，故而等待了2秒，之后又预消费了2个令牌acquire 2 时 …
通俗的讲「前人_挖坑_后人跳」,也就说上一次请求获取的permit数越多，那么下一次再获取授权时更待的时候会更长，反之，如果上一次获取的少，那么时间向后推移的就少，下一次获得许可的时间更短。可见，都是有代价的。正所谓：要浪漫就要付出代价。马上就七夕了，浪漫的代价可能要花钱啊，单身狗们。
令牌桶算法VS漏桶算法
漏桶
漏桶的出水速度是恒定的，那么意味着如果瞬时大流量的话，将有大部分请求被丢弃掉（也就是所谓的溢出）。
令牌桶
生成令牌的速度是恒定的，而请求去拿令牌是没有速度限制的。这意味，面对瞬时大流量，该算法可以在短时间内请求拿到大量令牌，而且拿令牌的过程并不是消耗很大的事情。
最后
不论是对于令牌桶拿不到令牌被拒绝，还是漏桶的水满了溢出，都是为了保证大部分流量的正常使用，而牺牲掉了少部分流量，这是合理的，如果因为极少部分流量需要保证的话，那么就可能导致系统达到极限而挂掉，得不偿失。
本文讲的单机的限流，是JVM级别的的限流，所有的令牌生成都是在内存中，在分布式环境下不能直接这么用，可用使redis限流。
第一种：根据时间滑动
介绍：比如统计每5秒内最高请求量是1000，那这个5秒是滑动的，从0到5秒，1到6秒，2到7秒以此类推最大请求量都是1000。要实现这种滑动的限流需要用到redis的zset结构。zset是一个有序的集合，uuid作为值，时间作为排序的分数，根据rangeByScore命令对时间进行排序，然后取出当前时间段内的请求量，红色部分是当前时间减去滑动窗口的时间。下面的代码是：每秒最多5个请求。
第二种：redis的list集合做令牌桶算法
介绍：令牌桶算法也称水桶算法，水桶算法意思是往水桶里面加水，然后再取水，如果取水速度大于加水速度就取不到水了，只能空手而归。我们现在往redis的list集合里面加元素，然后请求过来的时候从list里面取元素，取到了就继续执行任务，取不到就返回。
具体实现如下：这个是取令牌没有取到说明请求量过大，leftPop命令是取出数据，并且删除
放令牌可以用task实现，最好有个配置平台根据当前流量，服务器情况实现动态控制。rightPush是从右侧插入数据。
第三种：redis实现漏斗算法，它也是用list实现的。
https://www.jianshu.com/p/127a3bc6e85b
介绍：漏斗算法和水桶算法的思想刚好相反，一直往木桶里加水，水桶下面有个洞，一直往外流水，加水速度大于漏水速度水就会满，这个时候就不能再加了。有请求过来一直往list里加内容，我们再取内容，请求速度大于取出速度就返回了。
如何实现呢？哈哈大家有兴趣自己想想怎么实现吧
