主流的四种限流策略，我都可以通过redis实现，干货仅此一篇

引言

• 在web开发中功能是基石，除了功能以外运维和防护就是重头戏了。因为在网站运行期间可能会因为突然的访问量导致业务异常、也有可能遭受别人恶意攻击
• 所以我们的接口需要对流量进行限制。俗称的QPS也是对流量的一种描述
• 针对限流现在大多应该是令牌桶算法，因为它能保证更多的吞吐量。除了令牌桶算法还有他的前身漏桶算法和简单的计数算法
• 下面我们来看看这四种算法

固定时间窗口算法

• 固定时间窗口算法也可以叫做简单计数算法。网上有很多都将计数算法单独抽离出来。但是笔者认为计数算法是一种思想，而固定时间窗口算法是他的一种实现
• 包括下面滑动时间窗口算法也是计数算法的一种实现。因为计数如果不和时间进行绑定的话那么失去了限流的本质了。就变成了拒绝了

优点

• 在固定的时间内出现流量溢出可以立即做出限流。每个时间窗口不会相互影响
• 在时间单元内保障系统的稳定。保障的时间单元内系统的吞吐量上限

缺点

• 正如图示一样，他的最大问题就是临界状态。在临界状态最坏情况会受到两倍流量请求
• 除了临界的情况，还有一种是在一个单元时间窗内前期如果很快地消耗完请求阈值。那么剩下的时间将会无法请求。这样就会因为一瞬间的流量导致一段时间内系统不可用。这在互联网高可用的系统中是不能接受的。

实现

• 好了，关于原理介绍及优缺点我们已经了解了。下面我们动手实现它
• 首先我们在实现这种计数时，采用redis是非常好的选择。这里我们通过redis实现

controller

@RequestMapping(value = "/start",method = RequestMethod.GET)
    public Map start(@RequestParam Map paramMap) {
        return testService.startQps(paramMap);
    }

service

@Override
public Map startQps(Map paramMap) {
    //根据前端传递的qps上线
    Integer times = 100;
    if (paramMap.containsKey("times")) {
        times = Integer.valueOf(paramMap.get("times").toString());
    }
    String redisKey = "redisQps";
    RedisAtomicInteger redisAtomicInteger = new RedisAtomicInteger(redisKey, redisTemplate.getConnectionFactory());
    int no = redisAtomicInteger.getAndIncrement();
    //设置时间固定时间窗口长度 1S
    if (no == 0) {
        redisAtomicInteger.expire(1, TimeUnit.SECONDS);
    }
    //判断是否超限  time=2 表示qps=3
    if (no > times) {
        throw new RuntimeException("qps refuse request");
    }
    //返回成功告知
    Map map = new HashMap<>();
    map.put("success", "success");
    return map;
}

结果测试

• 我们设置的qps=3 ， 我们可以看到五个并发进来后前三个正常访问，后面两个就失败了。稍等一段时间我们在并发访问，前三个又可以正常访问。说明到了下一个时间窗口
  

滑动时间窗口算法

• 针对固定时间窗口的缺点–临界值出现双倍流量问题。 我们的滑动时间窗口就产生了。
• 其实很好理解，就是针对固定时间窗口，