接口限流（令牌桶算法、漏桶算法）

概述

每个借口都有处理请求的极限，也就是我们所说的TPS、QPS，如果对方法或者接口的调用不加限制，那么会有可能导致所有请求阻塞，导致请求接口的直接不能用，甚至让机器宕机。因此需要在方法或者接口调用的时候做限流处理，限制QPS、TPS。
解决思想：控制请求频率，要么直接拒绝，要么让其等待后续处理，或者引流。
两种限流算法：漏桶算法和令牌桶算法

漏桶算法

每个接口限定一个固定的处理请求能力，相当于一个固定的桶能承载的最大的水的容量，而这个桶的大小就是最多能处理的请求并发数能力，然后每处理完一个请求，那么漏桶里面的水就会漏出去一些，如果请求来的时候，漏桶已达到承载极限（水装满了），这时就是请求速度大于处理速度并且堆积的请求太多了的情况。最终漏桶的水将会溢出，就相当于拒绝了请求。

令牌桶算法（Token Bucket）

随着时间的流逝，在每过△=1/QPS的时间就会产生一个用于处理请求的token放入Bucket中，来一个请求那么就从这个令牌桶中拿一个token走，只有拥有token的请求才能被处理，如果没有拿到token，则阻塞等待或者直接拒绝请求。
形象描述：桶没有漏口，反而是有水龙头在一滴一滴地滴水，来个请求就取走一滴水去执行请求。

RateLimiter

这是google guava所提供的一个限流工具类，是基于令牌桶算法实现的。这个工具类的整体设计思想是第一个请求最先获取令牌并且会被立即执行，然后将随后的请求推迟到1/QPS时间后，这样就让任务的执行和等待同时进行，对于昂贵的获取令牌操作（即acquire时没有足够多的token）时，就让之前storepermits的令牌先执行，不够的先把推迟产生的token提前预约好（会让下一次请求等待到合适的时间点才让其获取到token），这样就提高了效率，加快了处理速度。
具体源码分析可借鉴博客：http://blog.csdn.net/zheng0518/article/details/51685895