google guava中提供了一个限流实现: RateLimiter，这个类设计的还是非常精巧，可以适用于我们日常业务中用于流控的场景。我们先了解一下限流的事情。
根据架构模型，你可能考虑在如下场景中实施限流：
1、代理层：比如SLB、nginx或者业务层gateway等，都支持限流，通常是基于连接数（或者并发数）、请求数进行限流，限流的维度通常是基于比如IP地址、资源位置、用户标志等，高级特性还可以根据自身负载情况动态调整限流策略（基准）。
2、服务调用者：服务调用方，基于本地限流，即此客户端可以限制某个远端服务的调用速率，超过阈值则可以进行阻塞或者拒绝，是限流的协作方。
3、服务接收方：基本同2，流量超过承载能力时，拒绝服务，通常基于应用本身的可靠性考虑，属于限流的主体方。我们常说的限流，一般发生在此处。本文主要结合RateLimiter讨论基于限流主体方的使用方式。
限流实施策略：
1、并发级别：比较易于实施的、简单的限流方式，它的使用场景也有着比较鲜明的特点：
1）每次请求，所需要的资源开支都比较均衡，比如，每个请求对CPU的消耗、IO消耗等，都差不多，请求的RT时间都基本接近。
2）请求密度或稀疏或高频，这个不是关注重点。
3）资源本身不需要繁琐的初始化工作（预热），或者初始化工作的开支可以忽略。
4）对待流量溢出的策略比较简单，通常时直接拒绝而不是等待，因为等待意味着限流主体可能需要额外的调度开支。
这种策略通常在适用在流量的顶层组件上，比如代理层对、中间件组件IO处理器等等对并发连接数的限制。对于JAVA语言，基于并发级别的限流，可以使用“信号量”等类似的计数器锁机制来实现，比如我的web站点限制最大并发请求数为200，无论请求的类型（即任何类型的请求，无论是高耗与否，总会占用一个处理线程以及相关的数据缓冲区），只要超出阈值，则直接拒绝。有些时候，你可能会适度支持溢出等待，此时需要额外的队列和调度策略来实现。
2、漏桶算法：请求流量以不确定是速率请求资源，资源处理以恒定的速率进行。有关漏桶模型，大家可以去研究一下相关资料。
1）桶：buffer，请求首先尝试进入队列，如果队列溢满，则拒绝此请求。进入队列以后，请求则等待执行，由此可见，请求究竟何时被执行，还存在一些变数，这直接取决于队列中pending的请求数。有时候，挑剔的设计者会考虑增加有关限制请求等待的时间阈值，这个时间就是请求入队、出队的最大时差。buffer的大小设计，通常与速率有直接关系。
2）漏：请求出队，这个出队，有些讲究，不同的设计理念实现就有所不同。有抢占式、有调度式，其中“抢占式”就是处理线程（或者进程，比如nginx worker进程）在上一个请求处理完毕之后即从buffer队列中poll新的请求，无论当前线程（或者进程）的处理速率是否超过设定的速率，这种策略下buffer大小就限定了速率的上限；调度式，就比较易于理解，需要额外的调度线程（进程），并严格按照设定的速率，从buffer中获取请求，并轮训的方式将请求交给其他worker线程，如果已有的worker线程繁忙，则直接创建新线程，目的就是确保速率是有保障的，这种方式下，buffer大小主要取决于等待时间。
3）溢出：就是因为漏桶的速率限制比较稳定，所以其面临流量突发（bursty）几乎没有应对能力，简单来说，超出buffer，就直接拒绝。
4）流量突发：尽管buffer的设计在一定层面上兼顾流量突发，但是还是太脆弱了，比如某个瞬间，请求密度很高（最尴尬的就是，只大了一点），将buffer溢满，或许buffer再“大一点点”就能够在合理时间内被处理；对于请求方，就会有些迷惑，“我只不过是稍微超了一点，你就给我响应一连串的拒绝信息”。
这种策略，也很常用，但是通常适用在限流的协作方，也是就客户端层面，请求发出之前，做流控，如果有溢出，是有很多可靠的策略来保障结果，比如重试等；反正“对面的服务压垮了，别怪我，我很自律”。
3、令牌桶：设计模型，我就不再介绍，大家可以去wiki深入了解一下。令牌桶的基本思想，跟老一辈的集体公社时代一样，每个月的供销是限额的，有资源才分配给个人，不足部分下个月再说，你可以排队赊账。
令牌的个数，就是可以允许获取资源的请求个数（我们假设每个请求只需要一个令牌），事实上，我们并不会真的去创建令牌实体，因为这是没有必要的，我们使用带有时间特征的计数器来表示令牌的可用个数即可。跟漏桶算法相比，令牌桶的“桶”不是用来buffer请求的、而是用来计量可用资源数量（令牌）的。虽然我们并不会创建令牌实体，但是仍然可以假想，这个桶内每个X时间就会新增一定数量的令牌，如果没有请求申请令牌，那么这个令牌桶是会溢出的...你会发现，这个设计跟漏桶算法从IO方向上是相反的。
那么漏桶算法的缺点，也正好成为了令牌桶的专长：流量突发；令牌桶成了buffer，如果请求密度低，或者处于冷却状态，那么令牌桶就会溢满，此后如果流量突发，则过去积累的结余资源则可以直接被“借用”。
令牌桶算法，使用场景很多，适应程度很高，现实中流量突发是常见的，而且从设计角度考虑，令牌桶更易于实现。回到正题，RateLimiter，就是一个基于令牌桶思想的实现。
RateLimiter原理讲解
此API的注释也基本上把它的设计思想阐述的比较清楚了,但是这个注释阅读起来还是稍微有点“哲学派”,我们从源码和实际使用层面来介绍它的核心思想。
//RateLimiter limiter = RateLimiter.create(10,2, TimeUnit.SECONDS);//QPS 100
RateLimiter limiter = RateLimiter.create(10);
long start = System.currentTimeMillis();
for (int i= 0; i < 30; i++) {
double time = limiter.acquire();
long after = System.currentTimeMillis() - start;
if (time > 0D) {
System.out.println(i + ",limited,等待:" + time + "，已开始" + after + "毫秒");
} else {
System.out.println(i + ",enough" + "，已开始" + after + "毫秒");
}
//模拟冷却时间，下一次loop可以认为是bursty开始
if (i == 9) {
Thread.sleep(2000);
}
}
System.out.println("total time：" + (System.currentTimeMillis() - start));
此例为简单的流控，只有一种资源，QPS为100；在实际业务场景中，可能不同的资源速率是不同的，我们可以创建N多个limeter各自服务于资源；此外limiter是线程安全的。
acquire()方法就是获取一个令牌（源码中使用permit，许可证），如果permit足够，则直接返回而无需等待，如果不足，则等待1/QPS秒。
此外，你会发现，limiter并没有类似于锁机制中的release()方法，这意味着“只要申请，总会成功”、且退出时也无需归还。
RateLimiter内部有两种实现：（如下阐述中，“资源”、“令牌”、“permits”为同一含义）
1、SmoothBursty：可以支持“突发流量”的限流器，即当限流器不被使用时间，可以额外存储一些permits以备突发流量，当突发流量发生时可以更快更充分的使用资源，流量平稳后（或者冷却期，积累的permits被使用完之后）速率处于限制状态。
其重点就是，冷却期间，permits会积累，且在突发流量时，可以消耗此前积累的permits而且无需任何等待。就像一个人，奔跑之后休息一段时间，再次起步可以有更高的速度。
由此可见，如果你的资源，冷却（不被使用）一段时间之后，再次被使用时可以提供比正常更高的效率，这个时候，你可以使用SmoothBursty。
创建方式：RateLimiter.create(double permitsPerSecond)
0,enough，已开始1毫秒 1,limited,等待:0.098623，已开始105毫秒 2,limited,等待:0.093421，已开始202毫秒 3,limited,等待:0.098287，已开始304毫秒 4,limited,等待:0.096025，已开始401毫秒 5,limited,等待:0.098969，已开始505毫秒 6,limited,等待:0.094892，已开始605毫秒 7,limited,等待:0.094945，已开始701毫秒 8,limited,等待:0.099145，已开始801毫秒 9,limited,等待:0.09886，已开始905毫秒 10,enough，已开始2908毫秒 11,enough，已开始2908毫秒 12,enough，已开始2908毫秒 13,enough，已开始2908毫秒 14,enough，已开始2908毫秒 15,enough，已开始2908毫秒 16,enough，已开始2908毫秒 17,enough，已开始2908毫秒 18,enough，已开始2908毫秒 19,enough，已开始2908毫秒 20,enough，已开始2909毫秒 21,limited,等待:0.099283，已开始3011毫秒 22,limited,等待:0.096308，已开始3108毫秒 23,limited,等待:0.099389，已开始3211毫秒 24,limited,等待:0.096674，已开始3313毫秒 25,limited,等待:0.094783，已开始3411毫秒 26,limited,等待:0.097161，已开始3508毫秒 27,limited,等待:0.099877，已开始3610毫秒 28,limited,等待:0.097551，已开始3713毫秒 29,limited,等待:0.094606，已开始3809毫秒 total time：3809
2、SmoothWarmingUp：具有warming up（预热）特性，即突发流量发生时，不能立即达到最大速率，而是需要指定的“预热时间”内逐步上升最终达到阈值；它的设计哲学，与SmoothBursty相反，当突发流量发生时，以可控的慢速、逐步使用资源（直到最高速率），流量平稳后速率处于限制状态。
其重点是，资源一直被使用，那么它可以持续限制稳定的速率；否则，冷却时间越长（有效时长为warmup间隔）获取permits时等待的时间越长，需要注意，冷却时间会积累permits，但是获取这些permits仍然需要等待。
由此可见，如果你的资源，冷却（不被使用）一段时间之后，再次被使用时它需要一定的准备工作，此时它所能提供的效率比正常要低；比如链接池、数据库缓存等。
创建方式：RateLimiter.create(double permitsPerSecond,long warnupPeriod,TimeUnit unit)
0,enough，已开始1毫秒 1,limited,等待:0.288847，已开始295毫秒 2,limited,等待:0.263403，已开始562毫秒 3,limited,等待:0.247548，已开始813毫秒 4,limited,等待:0.226932，已开始1041毫秒 5,limited,等待:0.208087，已开始1250毫秒 6,limited,等待:0.189501，已开始1444毫秒 7,limited,等待:0.165301，已开始1614毫秒 8,limited,等待:0.145779，已开始1761毫秒 9,limited,等待:0.128851，已开始1891毫秒 10,enough，已开始3895毫秒 11,limited,等待:0.289809，已开始4190毫秒 12,limited,等待:0.264528，已开始4458毫秒 13,limited,等待:0.247363，已开始4710毫秒 14,limited,等待:0.225157，已开始4939毫秒 15,limited,等待:0.206337，已开始5146毫秒 16,limited,等待:0.189213，已开始5337毫秒 17,limited,等待:0.167642，已开始5510毫秒 18,limited,等待:0.145383，已开始5660毫秒 19,limited,等待:0.125097，已开始5786毫秒 20,limited,等待:0.109232，已开始5898毫秒 21,limited,等待:0.096613，已开始5999毫秒 22,limited,等待:0.096321，已开始6098毫秒 23,limited,等待:0.097558，已开始6200毫秒 24,limited,等待:0.095132，已开始6299毫秒 25,limited,等待:0.095495，已开始6399毫秒 26,limited,等待:0.096352，已开始6496毫秒 27,limited,等待:0.098641，已开始6597毫秒 28,limited,等待:0.097883，已开始6697毫秒 29,limited,等待:0.09839，已开始6798毫秒 total time：6798
这两个类都继承自SmoothRateLimiter，最终继承自RateLimiter；RateLimiter内部核心的方法：
1）double acquire()：获取一个permit，如果permits充足则直接返回，否则等待1/QPS秒。此方法返回线程等待的时间（秒），如果返回0.0表示未限流、未等待。
2）double acquire(int n)：获取n个permits，如果permits充足则直接返回，否则限流并等待，等待时间为“不足的permits个数 / QPS”。（暂且这么解释）
acquire操作核心过程：
//伪代码
public double acquire(int requiredPermits) {
long waitTime = 0L;
synchronized(mutex) {
boolean cold = nextTicketTime > now;
if (cold) {
storedPermits = 根据冷却时长计算累积的permits;
nextTicketTime = now;
}
//根据storedPermits、requiredPermits计算需要等待的时间
//bursty：如果storePermits足够，则waitTime = 0
//warmup：平滑预热，storePermits越多（即冷却时间越长），等待时间越长
if(storedPermits不足) {
waitTime += 欠缺的permits个数 / QPS;
}
if(bursty限流) {
waitTime += 0;//即无需额外等待
}
if(warmup限流) {
waitTime += requiredPermits / QPS;
if(storedPermits > 0.5 * maxPermits) {
waitTime += 阻尼时间;
}
}
nextTicketTime += waitTime
}
if (waitTime > 0L) {
Thread.sleep(waitTime);
}
return waitTime;
}
1、Object mutex：同步锁，如上述伪代码所示，在计算存量permits、实际申请permits（包括计算）的过程中全部是同步的；我们需要知道，RateLimiter内部确实使用了锁同步机制。
2、maxPermits：最大可存储的许可数量（tickets数量），SmoothBursty和SmoothWarimingUp默认实现中，有所不同：
1）SmoothBusty，其值为maxBurstSecond * QPS，就是允许“突发流量持续时间” * QPS，这种设计可以理解，不过RateLimiter将maxBustSecond硬编码为1.0，最终此值等于QPS。
2）SmoothWarmingUp：默认算法值为warmupPeriod * QPS，简单说就是“预热时长” * QPS。
此参数主要限制，无论冷却多长时间，其storedPermits不能超过此值；此值在设定QPS之后，则不会再改变。
3、storedPermits：已存储的permits数量，此值取决于冷却时间，简单来说冷却的时间越久，此值越大，但不会超过maxPermits，起始值为0。
1）当一个请求，申请permit之前，将会计算上一次令牌申请（nexFreeTicketTime）的时间与now之间的时差，并根据令牌产生速率（1/QPS）计算此冷却期间可以存储的令牌数，也就是storedPermits。
2）permits申请完毕之后，将当前时间（如果需要等待，额外加上等待时间）作为下一次令牌申请的起始时间，此时冷却时间结束。
3）申请完毕之后，storedPermits将会减去申请的permits个数，直到为0。
冷却时长和申请频次，都决定了storedPermits大小，其中冷却时间会导致storePermits增加，acquire操作将导致storePermits减少。
4、nextFreeTicketMicros（时间戳，微妙单位）：下一个可以自由获取的令牌的时间，此值可以为未来的某个时间，此时表示限流已经开始，部分请求已经在等待，此值主要用来标记“冷却状态”。（赊账）
1）如果处于冷却期，那么此值通常是过去式，即此值小于now。
2）如果此时有请求申请permits，则会通过此值与now的时差，计算storedPermits，同时将此值设置为now。
3）如果此值是未来时刻，即大于now，则无需计算storedPermits，也无需重置此值。
4）申请tickets后，从storedPermits减去需要的tickets个数，如果触发限速等待（比如预热期、permits不足），则会将2）操作之后额外增加等待时间作为nextFreeTicketsTime值。
5）基于2），对于warmingUp限流，冷却期之后的首个请求是不需要等待的，只是将此值设置为now + 阻尼性质的等待时间waitTime（），这意味着在此后waitTime期间再有请求，则会触发等待，并继续延续nextFreeTicketMicros值。此值的延续，在warming up期间，阻尼waitTime计算比较复杂，由1/QPS + 额外值，这个额外值，随着预热时间增长而减小。
6）基于2），对于bursty限流，如果storedPermits大于0，则总是不需要等待，只是简单将此值设为为now；否则，则按照正常的1/QPS间隔计算其应该被推延的时间点。
5、对于warming up限流，将maxPermits * 0.5作为一个阈值分割线，当storedPermits小于此分割线时，在限流时使用正常等待时间（申请permits个数 / QPS）；在此分割线之上时，则4）增加额外阻尼，即预热阻尼。
6、我们发现，RateLimiter内部并不会真的生成tickets实体，而是根据冷却时长、在申请资源时才计算存量tickets（对应为storedPermits）。无论何种限流，storedPermits都是优先使用。
到此为止，我们已经基本了解RateLimiter内部的机制，我们需要注意几点：
1、RateLimiter是线程安全的，所以在并发环境中可以直接使用，而无需额外的lock或者同步；此外需要提一下，RateLimiter内部确实是使用了同步机制。
2、考虑到RateLimiter内部的同步锁，我们通常在实际业务开发中，每个资源（比如URL）使用各自的RateLimiter而不是公用一个。
3、它内部无额外的线程，也没有其他的数据结构用来存储tickets实体，所以它非常的轻量级。
4、RateLimiter最大的问题，就是acquire方法总会成功，内部的tickets时间点会向后推移；如果并发很高，严重超过rate阈值时，后续被限流的请求，其等待时间将会基于时间线累加，导致等待时间不可控。
5、为了避免4、问题，我们通常先使用tryAcquired检测，如果可行再去acquire；如果令牌不足，适当拒绝。所以基于RateLimiter，并没有内置的拒绝策略，这一点需要我们额外开发。
6、我们不能简单依赖于acquire方法，来实现限流等待，否则这可能带来严重问题。我们通常需要封装RateLimiter，并使用额外的属性记录其是否“处于限流状态”、“已经推延的tickets时间点”，如果“已经推延的时间点非常遥远”且超过可接受范围，则直接拒绝请求。简单来说，封装acquire方法，增加对请求可能等待时间的判断，如果超长，则直接拒绝。
7、RateLimiter存在一个很大的问题，就是几乎没法扩展：子类均为protected。
FollowCotroller.java：流控器，如果限流开始，则只能有max个请求因此而等待，超过此值则直接拒绝。
public class FollowController {
private final RateLimiter rateLimiter;
private int maxPermits;
private Object mutex = new Object();
//等待获取permits的请求个数，原则上可以通过maxPermits推算
private int maxWaitingRequests;
private AtomicInteger waitingRequests = new AtomicInteger(0);
public FollowController(int maxPermits,int maxWaitingRequests) {
this.maxPermits = maxPermits;
this.maxWaitingRequests = maxWaitingRequests;
rateLimiter = RateLimiter.create(maxPermits);
}
public FollowController(int permits,long warmUpPeriodAsSecond,int maxWaitingRequests) {
this.maxPermits = maxPermits;
this.maxWaitingRequests = maxWaitingRequests;
rateLimiter = RateLimiter.create(permits,warmUpPeriodAsSecond, TimeUnit.SECONDS);
}
public boolean acquire() {
return acquire(1);
}
public boolean acquire(int permits) {
boolean success = rateLimiter.tryAcquire(permits);
if (success) {
rateLimiter.acquire(permits);//可能有出入
return true;
}
if (waitingRequests.get() > maxWaitingRequests) {
return false;
}
waitingRequests.getAndAdd(permits);
rateLimiter.acquire(permits);
waitingRequests.getAndAdd(0 - permits);
return true;
}
}