使用Redis实现限流的几种方法

　　限流是高并发场景中重要的一环，实现限流的方案有很多种，今天围绕Redis来简单介绍几种限流方案。题外话：Redis不仅仅是可以做限流，还可以做数据统计、排行榜、附近的人等功能，有空我会写一篇介绍一下。

　　常见的限流算法有：计数器、滑动窗口、漏桶算法、令牌桶等。那么如何使用Redis来实现呢？

　 基于Redis的setnx的操作(计数器)

　　我们在使用Redis的分布式锁的时候，大家都知道是依靠了setnx的指令，在CAS（Compare and swap）的操作的时候，同时给指定的key设置了过期时间（expire）。限流的主要目的就是为了在单位时间内，有且仅有N数量的请求能够访问我的代码程序。所以依靠setnx可以很轻松的做到这方面的功能。

　　比如我们需要在10秒内限定20个请求，那么我们在setnx的时候可以设置过期时间10，当请求的setnx数量达到20时候即达到了限流效果。

// 限流的个数
private int maxCount = 10;
// 指定的时间内
private long interval = 60;
// 原子类计数器
private AtomicInteger atomicInteger = new AtomicInteger(0);
// 起始时间
private long startTime = System.currentTimeMillis();

public boolean limit(int maxCount, int interval) {
    atomicInteger.addAndGet(1);
    if (atomicInteger.get() == 1) {
        startTime = System.currentTimeMillis();
        atomicInteger.addAndGet(1);
        return true;
    }
    // 超过了间隔时间，直接重新开始计数
    if (System.currentTimeMillis() - startTime > interval * 1000) {
        startTime = System.currentTimeMillis();
        atomicInteger.set(1);
        return true;
    }
    // 还在间隔时间内,check有没有超过限流的个数
    if (atomicInteger.get() > maxCount) {
        return false;
    }
    return true;
} 

　　当然这种做法的弊端是很多的，比如当统计1-10秒的时候，无法统计2-11秒之内，如果需要统计N秒内的M个请求，那么我们的Redis中需要保持N个key等等问题。

    基于Redis的数据结构zset(滑动窗口)

　　上面的计数器算法存在的弊端，使用滑动窗口可以很容易的实现。上面提到的1-10怎么变成2-11，其实可以理解为窗口大小不变，变化的是窗口的启始结束位置，而我们如果用Redis的list数据结构可以轻而易举的实现该功能。

　　我们可以将请求打造成一个zset数组，当每一次请求进来的时候，value保持唯一，可以用UUID生成，而score可以用当前时间戳表示，因为score我们可以用来计算当前时间戳之内有多少的请求数量。而zset数据结构也提供了range方法让我们可以很轻易的获取到2个时间戳内有多少请求

　　代码实现也比较简单，

public Response limitFlow(){
    Long currentTime = new Date().getTime();
    System.out.println(currentTime);
    if(redisTemplate.hasKey("limit")) {
        Integer count = redisTemplate.opsForZSet().rangeByScore("limit", currentTime -  intervalTime, currentTime).size();        // intervalTime是限流的时间 
        System.out.println(count);
        if (count != null && count > 5) {
            return Response.ok("每分钟最多只能访问5次");
        }
    }
    redisTemplate.opsForZSet().add("limit",UUID.randomUUID().toString(),currentTime);
    return Response.ok("访问成功");
}　

　 漏桶算法

　　漏桶算法思路很简单，用一个漏斗来控制请求的速率。在漏斗上方是收到的所有请求，请求就像水一样会进入漏斗中，同时漏斗也会以恒定的速度将水（请求）从下方进行排出，被排出的水（请求）才能访问服务。当请求量不大时候，如进水速率 < 出水速率那么其实漏斗并没有起到作用；当请求量很大的时候，超过漏斗容量的请求将被溢出，并且出水口可以一直保证恒定的速率。

　 基于Redis的令牌桶算法

　　提到限流就不得不提到令牌桶算法了。令牌桶算法提及到输入速率和输出速率，当输出速率大于输入速率，那么就是超出流量限制了。

　　也就是说我们每访问一次请求的时候，可以从Redis中获取一个令牌，如果拿到令牌了，那就说明没超出限制，而如果拿不到，则结果相反。可以理解成医院的挂号看病，只有拿到号以后才可以进行诊病。依靠上述的思想，我们可以结合Redis的List数据结构很轻易的做到这样的代码，只是简单实现。另外，关注互联网架构师，在后台回复：2T，可以获取我整理的 Redis 系列面试题和答案，非常齐全。

　　依靠List的leftPop来获取令牌　

public Response limitFlow(Long id){
    Object result = redisTemplate.opsForList().leftPop("limit_list");
    if(result == null){
        return Response.ok("当前令牌桶中无令牌");
    }
    return Response.ok("访问成功"); 
}

　　再依靠Java的定时任务，定时往List中rightPush令牌，当然令牌也需要唯一性，所以我这里还是用UUID进行了生成.一旦需要提高速率，则按需提高放入桶中的令牌的速率即可。

@Scheduled(fixedDelay = 100,initialDelay = 0)
public void setIntervalTimeTask(){
    redisTemplate.opsForList().rightPush("limit_list",UUID.randomUUID().toString());
}

 　　网上还有Redis+Lua的实现方案，鉴于对Lua不熟悉就不介绍了，有兴趣的同学可以去研究下，当然有比较有创意的方案也可以一块讨论下。