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

最新推荐文章于 2024-08-30 18:14:39 发布

面试狗哦

最新推荐文章于 2024-08-30 18:14:39 发布

阅读量1k

点赞数 20

分类专栏： 2024年程序员学习文章标签： redis bootstrap 前端

本文链接：https://blog.csdn.net/m0_60452134/article/details/137631012

版权

2024年程序员学习专栏收录该内容

322 篇文章 1 订阅

订阅专栏

实现

滑动时间窗口是将时间更加细化，上面我们是通过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;

结果测试

主流的四种限流策略，我都可以通过redis实现

和固定时间窗口采用相同的并发。为什么上面也会出现临界状况呢。因为在代码里时间单元间隔比固定时间间隔采用还要大。上面演示固定时间窗口时间单元是1S出现了最坏情况。而滑动时间窗口设计上就应该间隔更短。而我设置成10S 也没有出现坏的情况
这里就说明滑动比固定的优处了。如果我们调更小应该更加不会出现临界问题，不过说到底他还是避免不了临界出现的问题

漏桶算法

滑动时间窗口虽然可以极大程度地规避临界值问题，但是始终还是避免不了
另外时间算法还有个致命的问题，他无法面对突如其来的大量流量，因为他在达到限流后直接就拒绝了其他额外流量
针对这个问题我们继续优化我们的限流算法。漏桶算法应运而生

主流的四种限流策略，我都可以通过redis实现

优点

面对限流更加的柔性，不再粗暴的拒绝。
增加了接口的接收性
保证下流服务接收的稳定性。均匀下发

缺点

我觉得没有缺点。非要鸡蛋里挑骨头那我只能说漏桶容量是个短板

实现

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次访问。我们可以发现只有在一开始能达到比较高的吞吐量。在随后桶的容量满了之后。而下游水滴速率比上游请求速率慢的情况下。只能以下游恒定的速度接收访问。
他的问题也暴露得很明显。针对时间窗口的不足漏桶进行的不足，但是仍是不足。无法彻底避免请求溢出的问题。
请求溢出本身就是一种灾难性的问题。所有的算法目前都没有解决这个问题。只是在减缓他带来的问题

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。