结果测试
- 我们设置的qps=3 ， 我们可以看到五个并发进来后前三个正常访问，后面两个就失败了。稍等一段时间我们在并发访问，前三个又可以正常访问。说明到了下一个时间窗口
-
针对固定时间窗口的缺点–临界值出现双倍流量问题。 我们的滑动时间窗口就产生了。
-
其实很好理解，就是针对固定时间窗口，将时间窗口统计从原来的固定间隔变成更加细度化的单元了。
-
在上面我们固定时间窗口演示中我们设置的时间单元是1S 。 针对1S我们将1S拆成时间戳。
-
固定时间窗口是统计单元随着时间的推移不断向后进行。而滑动时间窗口是我们认为的想象出一个时间单元按照相对论的思想将时间固定，我们的抽象时间单元自己移动。抽象的时间单元比实际的时间单元更小。
-
读者可以看下下面的动图，就可以理解了。
优点
-
实质上就是固定时间窗口算法的改进。所以固定时间窗口的缺点就是他的优点。
-
内部抽象一个滑动的时间窗，将时间更加小化。存在边界的问题更加小。客户感知更弱了。
缺点
-
不管是固定时间窗口算法还是滑动时间窗口算法，他们都是基于计数器算法进行优化，但是他们对待限流的策略太粗暴了。
-
为什么说粗暴呢，未限流他们正常放行。一旦达到限流后就会直接拒绝。这样我们会损失一部分请求。这对于一个产品来说不太友好
实现
-
滑动时间窗口是将时间更加细化，上面我们是通过redis#setnx实现的。这里我们就无法通过他统一记录了。我们应该加上更小的时间单元存储到一个集合汇总。然后根据集合的总量计算限流。redis的zsett数据结构就和符合我们的需求。
-
为什么选择zset呢，因为redis的zset中除了值以外还有一个权重。会根据这个权重进行排序。如果我们将我们的时间单元及时间戳作为我们的权重，那么我们获取统计的时候只需要按照一个时间戳范围就可以了。
-
因为zset内元素是唯一的，所以我们的值采用uuid或者雪花算法一类的id生成器
controller
@RequestMapping(value = “/startList”,method = RequestMethod.GET)
public Map<String,Object> startList(@RequestParam Map<String, Object> paramMap) {
return testService.startList(paramMap);
}
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;
结果测试
-
和固定时间窗口采用相同的并发。为什么上面也会出现临界状况呢。因为在代码里时间单元间隔比固定时间间隔采用还要大 。 上面演示固定时间窗口时间单元是1S出现了最坏情况。而滑动时间窗口设计上就应该间隔更短。而我设置成10S 也没有出现坏的情况
-
这里就说明滑动比固定的优处了。如果我们调更小应该更加不会出现临界问题，不过说到底他还是避免不了临界出现的问题
-
滑动时间窗口虽然可以极大程度地规避临界值问题，但是始终还是避免不了
-
另外时间算法还有个致命的问题，他无法面对突如其来的大量流量，因为他在达到限流后直接就拒绝了其他额外流量
-
针对这个问题我们继续优化我们的限流算法。 漏桶算法应运而生
优点
-
面对限流更加的柔性，不再粗暴的拒绝。
-
增加了接口的接收性
-
保证下流服务接收的稳定性。均匀下发
缺点
- 我觉得没有缺点。非要鸡蛋里挑骨头那我只能说漏桶容量是个短板
实现
controller
@RequestMapping(value = “/startLoutong”,method = RequestMethod.GET)
public Map<String,Object> startLoutong(@RequestParam Map<String, Object> paramMap) {
return testService.startLoutong(paramMap);
}
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;
}
下游消费
@Component
public class SchedulerTask {
@Autowired
RedisTemplate redisTemplate;
private String redisKey=“qpsList”;
@Scheduled(cron=“*/1 * * * * ?”)
private void process(){
//一次性消费两个
System.out.println(“正在消费。。。。。。”);
redisTemplate.opsForList().trim(redisKey, 2, -1);
}
}
测试
-
我们还是通过50并发循环10次访问。我们可以发现只有在一开始能达到比较高的吞吐量。在随后桶的容量满了之后。而下游水滴速率比上游请求速率慢的情况下。只能以下游恒定的速度接收访问。
-
他的问题也暴露得很明显。针对时间窗口的不足漏桶进行的不足，但是仍是不足。无法彻底避免请求溢出的问题。
-
请求溢出本身就是一种灾难性的问题。所有的算法目前都没有解决这个问题。只是在减缓他带来的问题
-
令牌桶和漏桶法是一样的。只不过将桶的作用方向改变了一下。
-
漏桶的出水速度是恒定的，如果流量突然增加的话我们就只能拒绝入池
-
但是令牌桶是将令牌放入桶中，我们知道正常情况下令牌就是一串字符当桶满了就拒绝令牌的入池，但是面对高流量的时候正常加上我们的超时时间就留下足够长的时间生产及消费令牌了。这样就尽可能地不会造成请求的拒绝
-
最后，不论是对于令牌桶拿不到令牌被拒绝，还是漏桶的水满了溢出，都是为了保证大部分流量的正常使用，而牺牲掉了少部分流量
public Map<String, Object> startLingpaitong(Map<String, Object> paramMap) {
String redisKey = “lingpaitong”;
String token = redisTemplate.opsForList().leftPop(redisKey).toString();
//正常情况需要验证是否合法，防止篡改
if (StringUtils.isEmpty(token)) {
throw new RuntimeException(“令牌桶拒绝”);
}
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）
最后
按照上面的过程，4个月的时间刚刚好。当然Java的体系是很庞大的，还有很多更高级的技能需要掌握，但不要着急，这些完全可以放到以后工作中边用别学。
学习编程就是一个由混沌到有序的过程，所以你在学习过程中，如果一时碰到理解不了的知识点，大可不必沮丧，更不要气馁，这都是正常的不能再正常的事情了，不过是“人同此心，心同此理”的暂时而已。
“道路是曲折的，前途是光明的！”
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
Java的体系是很庞大的，还有很多更高级的技能需要掌握，但不要着急，这些完全可以放到以后工作中边用别学。
学习编程就是一个由混沌到有序的过程，所以你在学习过程中，如果一时碰到理解不了的知识点，大可不必沮丧，更不要气馁，这都是正常的不能再正常的事情了，不过是“人同此心，心同此理”的暂时而已。
“道路是曲折的，前途是光明的！”
[外链图片转存中…(img-wTmeLSb7-1713569476260)]
[外链图片转存中…(img-ybfDwYC2-1713569476262)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
1275
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
