@Override
public Map<String, Object> startQps(Map<String, Object> 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<String, Object> map = new HashMap<>();
map.put("success", "success");
return map;}
### [](https://gitee.com/vip204888/java-p7)结果测试
* 我们设置的qps=3 ， 我们可以看到五个并发进来后前三个正常访问，后面两个就失败了。稍等一段时间我们在并发访问，前三个又可以正常访问。说明到了下一个时间窗口
[](https://gitee.com/vip204888/java-p7)滑动时间窗口算法
===========================================================================
* 针对固定时间窗口的缺点–临界值出现双倍流量问题。 我们的滑动时间窗口就产生了。
* 其实很好理解，就是针对固定时间窗口，将时间窗口统计从原来的固定间隔变成更加细度化的单元了。
* 在上面我们固定时间窗口演示中我们设置的时间单元是1S 。 针对1S我们将1S拆成时间戳。
* 固定时间窗口是统计单元随着时间的推移不断向后进行。而滑动时间窗口是我们认为的想象出一个时间单元按照相对论的思想将时间固定，我们的抽象时间单元自己移动。抽象的时间单元比实际的时间单元更小。
* 读者可以看下下面的动图，就可以理解了。
[](https://gitee.com/vip204888/java-p7)优点
---------------------------------------------------------------------
* 实质上就是固定时间窗口算法的改进。所以固定时间窗口的缺点就是他的优点。
* 内部抽象一个滑动的时间窗，将时间更加小化。存在边界的问题更加小。客户感知更弱了。
[](https://gitee.com/vip204888/java-p7)缺点
---------------------------------------------------------------------
* 不管是固定时间窗口算法还是滑动时间窗口算法，他们都是基于计数器算法进行优化，但是他们对待限流的策略太粗暴了。
* 为什么说粗暴呢，未限流他们正常放行。一旦达到限流后就会直接拒绝。这样我们会损失一部分请求。这对于一个产品来说不太友好
[](https://gitee.com/vip204888/java-p7)实现
---------------------------------------------------------------------
* 滑动时间窗口是将时间更加细化，上面我们是通过redis#setnx实现的。这里我们就无法通过他统一记录了。我们应该加上更小的时间单元存储到一个集合汇总。然后根据集合的总量计算限流。redis的zsett数据结构就和符合我们的需求。
* 为什么选择zset呢，因为redis的zset中除了值以外还有一个权重。会根据这个权重进行排序。如果我们将我们的时间单元及时间戳作为我们的权重，那么我们获取统计的时候只需要按照一个时间戳范围就可以了。
* 因为zset内元素是唯一的，所以我们的值采用uuid或者雪花算法一类的id生成器
### [](https://gitee.com/vip204888/java-p7)controller
@RequestMapping(value = "/startList",method = RequestMethod.GET)
public Map<String,Object> startList(@RequestParam Map<String, Object> paramMap) {
return testService.startList(paramMap);
}
### [](https://gitee.com/vip204888/java-p7)service
String redisKey = "qpsZset";
Integer times = 100;
if (paramMap.containsKey("times")) {
times = Integer.valueOf(paramMap.get("times").toString());
}
long currentTimeMillis = System.currentTimeMillis();
long interMills = inter * 1000L;
Long count = redisTemplate.opsForZSet().count(redisKey, currentTimeMillis - interMills, currentTimeMillis);
if (count > times) {
throw new RuntimeException("qps refuse request");
}
redisTemplate.opsForZSet().add(redisKey, UUID.randomUUID().toString(), currentTimeMillis);
Map<String, Object> map = new HashMap<>();
map.put("success", "success");
return map;
### [](https://gitee.com/vip204888/java-p7)结果测试
* 和固定时间窗口采用相同的并发。为什么上面也会出现临界状况呢。因为在代码里时间单元间隔比固定时间间隔采用还要大 。 上面演示固定时间窗口时间单元是1S出现了最坏情况。而滑动时间窗口设计上就应该间隔更短。而我设置成10S 也没有出现坏的情况
* 这里就说明滑动比固定的优处了。如果我们调更小应该更加不会出现临界问题，不过说到底他还是避免不了临界出现的问题
[](https://gitee.com/vip204888/java-p7)漏桶算法
=======================================================================
* 滑动时间窗口虽然可以极大程度的规避临界值问题，但是始终还是避免不了
* 另外时间算法还有个致命的问题，他无法面对突如其来的大量流量，因为他在达到限流后直接就拒绝了其他额外流量
* 针对这个问题我们继续优化我们的限流算法。 漏桶算法应运而生
[](https://gitee.com/vip204888/java-p7)优点
---------------------------------------------------------------------
* 面对限流更加的柔性，不在粗暴的拒绝。
* 增加了接口的接收性
* 保证下流服务接收的稳定性。均匀下发
[](https://gitee.com/vip204888/java-p7)缺点
---------------------------------------------------------------------
* 我觉得没有缺点。非要鸡蛋里挑骨头那我只能说漏桶容量是个短板
[](https://gitee.com/vip204888/java-p7)实现
---------------------------------------------------------------------
### [](https://gitee.com/vip204888/java-p7)controller
@RequestMapping(value = "/startLoutong",method = RequestMethod.GET)
public Map<String,Object> startLoutong(@RequestParam Map<String, Object> paramMap) {
return testService.startLoutong(paramMap);}
### [](https://gitee.com/vip204888/java-p7)service
* 在service中我们通过redis的list的功能模拟出桶的效果。这里代码是实验室性质的。在真实使用中我们还需要考虑并发的问题
@Override
public Map<String, Object> startLoutong(Map<String, Object> paramMap) {
String redisKey = "qpsList";
Integer times = 100;
if (paramMap.containsKey("times")) {
times = Integer.valueOf(paramMap.get("times").toString());
}
Long size = redisTemplate.opsForList().size(redisKey);
if (size >= times) {
throw new RuntimeException("qps refuse request");
}
Long aLong = redisTemplate.opsForList().rightPush(redisKey, paramMap);
if (aLong > times) {
//为了防止并发场景。这里添加完成之后也要验证。 即使这样本段代码在高并发也有问题。此处演示作用
redisTemplate.opsForList().trim(redisKey, 0, times-1);
throw new RuntimeException("qps refuse request");
}
Map<String, Object> map = new HashMap<>();
map.put("success", "success");
return map;}
### [](https://gitee.com/vip204888/java-p7)下游消费
言尽于此，完结
无论是一个初级的 coder，高级的程序员，还是顶级的系统架构师，应该都有深刻的领会到设计模式的重要性。
- 第一，设计模式能让专业人之间交流方便，如下：
程序员A：这里我用了XXX设计模式
程序员B：那我大致了解你程序的设计思路了
- 第二，易维护
项目经理：今天客户有这样一个需求…
程序员：明白了，这里我使用了XXX设计模式，所以改起来很快
- 第三，设计模式是编程经验的总结
程序员A：B，你怎么想到要这样去构建你的代码
程序员B：在我学习了XXX设计模式之后，好像自然而然就感觉这样写能避免一些问题
- 第四，学习设计模式并不是必须的
程序员A：B，你这段代码使用的是XXX设计模式对吗？
程序员B：不好意思，我没有学习过设计模式，但是我的经验告诉我是这样写的
从设计思想解读开源框架，一步一步到Spring、Spring5、SpringMVC、MyBatis等源码解读，我都已收集整理全套，篇幅有限，这块只是详细的解说了23种设计模式，整理的文件如下图一览无余！
搜集费时费力，能看到此处的都是真爱！
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/123163.html