面试官：你知道哪些限流算法？

一般做接口限流主要是为了应对突发流量，避免突发流量拖垮服务。如下面一些场景就有可能发生突发流量

1. 微博热搜
2. 恶意刷单
3. 恶意爬虫
4. 促销活动

接口限流的算法有如下几种：

1、计数器（固定窗口）算法

计数器算法是使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略。下一个周期开始时，进行清零，重新计数。

此算法在单机还是分布式环境下实现都非常简单，使用redis的incr原子自增性和线程安全即可轻松实现。

伪代码：

int unitTime = 1s //设置单位时间为1s
int limitCount = 1000 //设置单位时间只能1000次请求
string limitKey = "limitkey"; //单位时间限流状态key


if（!has（limitKey））{
    //初始化单位时间限流状态，并设定期有效期（有效期为一个单位时间）
    //参考redis的set命令
    set（limitKey,0,unitTime）
}


//原子递增请求量，并返回当前单位时间已有的请求数
int counter = incr（limitKey,1）


if(counter>limitCount)
    //超出设置的限流规则，直接返回503（也可自定义返回内容）
    return 503 
else
    continue;//继续执行业务逻辑   

这个算法通常用于QPS限流和统计总访问量，对于秒级以上的时间周期来说，会存在一个非常严重的问题，那就是临界问题（突刺现象）：

假设1s内服务器的负载能力为1000，因此一个周期的访问量限制在1000，然而在第一个周期的最后200微秒和下一个周期的开始200微秒时间段内，分别涌入800的访问量，虽然没有超过每个周期的限制量，但是整体上400微秒内已达到1600的访问量，已远远超过服务器的负载能力，由此可见，计数器算法方式限流对于周期比较长的限流，存在很大的弊端。

2、滑动窗口算法

滑动窗口算法是将时间周期分为N个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期。

假设时间周期为1s，将1s再分为2个小周期，统计每个小周期的访问数量，则可以看到，第一个时间周期内，访问数量为1000，第二个时间周期内，访问数量为1000，超过1000的访问可以被限流掉

由此可见，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

此算法可以很好的解决固定窗口算法的临界问题。

int unitTime = 1000ms //设置单位时间为1s（1000ms）
int limitCount = 1000 //设置单位时间只能1000次请求
string listKey = 'limitkey'; //单位时间限流状态key


//获取当前毫秒数
int curMilliseconds = nowMilliseconds（）;
//计算单位时间的起始时间
int startMilliseconds = curMilliseconds-unitTime*1000 //获取单位时间的起始时间


//获取当前往前推1s 之内的所有请求量（这一步及耗性能）
//参考redis的ZCOUNT命令
int counter = ZCOUNT（listKey,startMilliseconds,curMilliseconds）


if counter>limitCount
    //超出设置的限流规则，直接返回503（也可自定义返回内容）
    return 503 
else
    ZADD（listKey,curMilliseconds,唯一标识）
    continue;//继续执行业务逻辑   
end

3、漏桶算法

漏桶算法是访问请求到达时直接放入漏桶，如当前容量已达到上限（限流值），则进行丢弃（触发限流策略）。漏桶以固定的速率进行释放访问请求（即请求通过），直到漏桶为空。

漏桶算法参考家里使用的漏斗你就能明白了，往漏斗里面倒水，不论倒多少水，下面出水的速率是恒定的。当漏斗满了，多余的水就被直接丢弃了。

类比流量，每秒处理的速率是恒定的，如果有大量的流量过来就先放到漏斗里面。当漏斗也满了，请求则被丢弃。

实现：用队列保存请求，用ScheduledThreadPoolExecutor（支持定时任务的线程池）来定时从队列中取请求来执行

4、令牌桶算法

令牌桶算法可以说是对漏桶算法的改进。漏桶算法能限制请求的速率。而令牌桶算法在限制请求速率的同时还允许一定程度的突发调用

令牌桶算法是程序以r（r=时间周期/限流值）的速度向令牌桶中增加令牌，直到令牌桶满，请求到达时向令牌桶请求令牌，如获取到令牌则通过请求，否则触发限流策略。

过程如下

一直放令牌，如果令牌桶达到上限则丢弃令牌，假设每秒放10个
可以应对一定程度的流量激增，如此时令牌桶有100个令牌，突然发生200次调用，则此时最开始的100次请求可以正常调用，后续的请求才会以10个/s的速率来调用
实现：用队列保存令牌，用ScheduledThreadPoolExecutor来定时放令牌

一般使用google提供的guava工具包即可

加入依赖：

 <dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>18.0</version>
</dependency>

public class RateLimiterDemo {
    public static void main(String[] args) {
        // 每秒生成2个令牌
        RateLimiter rateLimiter = RateLimiter.create(2);
        for (int i = 0; i < 12; i++) {
            new Thread(() -> {
                // 获得令牌
                rateLimiter.acquire();
                System.out.println(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date()));
            }).start();
        }
    }
}

rateLimiter提供了acquire()和tryAcquire()方法

1. acquire()方法，如果没有可用令牌，会一直阻塞到获得令牌
2. tryAcquire()方法，如果没有可用令牌，则直接返回false，可以设置超时获取