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

最新推荐文章于 2024-08-09 09:48:48 发布

2401_83977357

最新推荐文章于 2024-08-09 09:48:48 发布

阅读量1k

点赞数 29

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

本文链接：https://blog.csdn.net/2401_83977357/article/details/137187956

版权

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

201 篇文章 0 订阅

订阅专栏

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

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

令牌桶算法

令牌桶和漏桶法是一样的。只不过将桶的作用方向改变了一下。
漏桶的出水速度是恒定的，如果流量突然增加的话我们就只能拒绝入池
但是令牌桶是将令牌放入桶中，我们知道正常情况下令牌就是一串字符当桶满了就拒绝令牌的入池，但是面对高流量的时候正常加上我们的超时时间就留下足够长的时间生产及消费令牌了。这样就尽可能地不会造成请求的拒绝

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

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

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