iis服务器助手广告广告
返回顶部
首页 > 资讯 > 后端开发 > 其他教程 >详解基于redis实现的四种常见的限流策略
  • 923
分享到

详解基于redis实现的四种常见的限流策略

2024-04-02 19:04:59 923人浏览 薄情痞子
摘要

目录一、引言二、固定时间窗口算法三、滑动时间窗口算法四、漏桶算法五、令牌桶算法一、引言 在web开发中功能是基石,除了功能以外运维和防护就是重头菜了。因为在网站运行期间可能

一、引言

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

二、固定时间窗口算法

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

优点:

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

缺点:

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

实现:

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

controller


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

service


@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;
}

结果测试

我们设置的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("令牌桶拒绝");
    }
    Map<string, object=""> map = new HashMap<>();
    map.put("success", "success");
    return map;
}

@Scheduled(cron="*/1 * * * * ?")
private void process(){
    //一次性生产两个
    System.out.println("正在消费。。。。。。");
    for (int i = 0; i < 2; i++) {
        redisTemplate.opsForList().rightPush(redisKey, i);
    }
}

以上就是详解基于redis实现的四种常见的限流策略的详细内容,更多关于redis限流策略的资料请关注编程网其它相关文章!

--结束END--

本文标题: 详解基于redis实现的四种常见的限流策略

本文链接: https://www.lsjlt.com/news/128544.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

本篇文章演示代码以及资料文档资料下载

下载Word文档到电脑,方便收藏和打印~

下载Word文档
猜你喜欢
  • 详解基于redis实现的四种常见的限流策略
    目录一、引言二、固定时间窗口算法三、滑动时间窗口算法四、漏桶算法五、令牌桶算法一、引言 在web开发中功能是基石,除了功能以外运维和防护就是重头菜了。因为在网站运行期间可能...
    99+
    2024-04-02
  • redis实现的四种常见限流策略
    目录引言固定时间窗口算法实现滑动时间窗口算法实现漏桶算法实现令牌桶算法引言 在web开发中功能是基石,除了功能以外运维和防护就是重头菜了。因为在网站运行期间可能会因为突然的...
    99+
    2024-04-02
  • 详解Redis实现限流的三种方式
     面对越来越多的高并发场景,限流显示的尤为重要。       当然,限流有许多种实现的方式,Redis具有很强大的功能,我用Redis实践了三...
    99+
    2024-04-02
  • 基于Redis的限流器的实现(示例讲解)
    1 概述 系统中的接口通常都有限流,比如 70次/秒 ,如何保证我们的接口的调用次数在超过第三方接口限流的时候快速失败呢?这时候就需要限流器了。下面是笔者用redis实现限流器的流程图。 2 代码 ...
    99+
    2024-04-02
  • 基于 Redis 实现接口限流的方式
    目录基于 Redis 实现接口限流1. 准备工作2. 限流注解3. 定制 RedisTemplate4. 开发 Lua 脚本5. 注解解析6. 接口测试7. 全局异常处理总结基于 R...
    99+
    2024-04-02
  • Redis限流的几种实现
    目录一、简单的限流 基本原理 二、漏斗限流 基本原理Redis-Cell 参考来源 一、简单的限流 基本原理 当系统处理能力有限,如何组织计划外的请求对系统施压。首先我们先看下一...
    99+
    2024-04-02
  • Java线程池的四种拒绝策略详解
    目录预先配置配置线程池。创建线程任务拒绝策略一:AbortPolicy拒绝策略二:CallerRunsPolicy拒绝策略三:DiscardPolicy拒绝策略四:DiscardOl...
    99+
    2024-04-02
  • Redis三种常用的缓存读写策略步骤详解
    目录一、Redis三种常用的缓存读写策略二、旁路缓存模式(Cache Aside Pattern)读写步骤写:读:自我思考缺点三、读写穿透(Read/Write Through Pa...
    99+
    2024-04-02
  • Redis数据过期策略的实现详解
    目录一、设置过期时间1、常用方式2、字符串独有方式二、3种过期策略三、Redis采用的过期策略四、RDB对过期key的处理五、AOF对过期key的处理  本文对Redis的过期机制简...
    99+
    2024-04-02
  • 关于Redis的内存淘汰策略详解
    目录一、什么是内存淘汰?二、Redis 内存上限三、Redis 内存淘汰策略四、内存淘汰的具体工作步骤五、LRU 算法及在 Redis 中的改进5.1 LRU 算法5.2 Redis 中的 LRU 算法六、LFU一、什么...
    99+
    2023-05-19
    Redis 策略 Redis 内存淘汰
  • Go+Redis实现常见限流算法的示例代码
    目录固定窗口滑动窗口hash实现list实现漏桶算法令牌桶滑动日志总结限流是项目中经常需要使用到的一种工具,一般用于限制用户的请求的频率,也可以避免瞬间流量过大导致系统崩溃,或者稳定消息处理速率。并且有时候我们还需要使用...
    99+
    2023-04-02
    Go Redis实现限流算法 Go Redis限流算法 Go 限流算法
  • 基于Redis实现分布式应用限流的方法
    限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统,一旦达到限制速率则可以拒绝服务。前几天在DD的公众号,看了一篇关于使用 瓜娃 实现单应用限流的方案 --》原文,参考《redis in action》 实...
    99+
    2023-05-30
    redis 限流 流的
  • Python实现排序方法常见的四种
    1.冒泡排序,相邻位置比较大小,将比较大的(或小的)交换位置 def maopao(a): for i in range(0,len(a)): for j...
    99+
    2024-04-02
  • Java限流实现的几种方法详解
    目录计数器信号量滑动窗口漏桶令牌桶测试示例代码计数器 计数器限流方式比较粗暴,一次访问就增加一次计数,在系统内设置每 N 秒的访问量,超过访问量的访问直接丢弃,从而实现限流访问。 具...
    99+
    2022-12-03
    Java限流 Java限流算法 Java限流方案
  • Java常见的限流算法详细分析并实现
    目录为什么要限流限流算法计数器限流漏桶限流令牌桶限流为什么要限流 在保证可用的情况下尽可能多增加进入的人数,其余的人在排队等待,或者返回友好提示,保证里面的进行系统的用户可以正常使用...
    99+
    2024-04-02
  • Java常见的限流算法怎么实现
    这篇“Java常见的限流算法怎么实现”文章的知识点大部分人都不太理解,所以小编给大家总结了以下内容,内容详细,步骤清晰,具有一定的借鉴价值,希望大家阅读完这篇文章能有所收获,下面我们一起来看看这篇“Java常见的限流算法怎么实现”文章吧。为...
    99+
    2023-06-29
  • VNPY中基于Ta-lib的KDJ策略怎样实现
    本篇文章给大家分享的是有关VNPY中基于Ta-lib的KDJ策略怎样实现,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。VNPY自带演示策略中,没有kdj策略,作为一个国内常用策...
    99+
    2023-06-05
  • OpenCV实现常见的四种图像几何变换
    目录准备图片1. 缩放 cv2.resize()方法2. 翻转 cv2.flip()方法3. 仿射变换 warpAffine()方法3.1 平移3.2 旋转3.3 倾斜4. 透视准备...
    99+
    2024-04-02
  • Golang怎么实现常见的限流算法
    本篇内容介绍了“Golang怎么实现常见的限流算法”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!固定窗口每开启一个新的窗口,在窗口时间大小内...
    99+
    2023-07-05
  • Redis实现限流器的三种方法(小结)
    目录方法一:基于Redis的setnx的操作方法二:基于Redis的数据结构zset方法三:基于Redis的令牌桶算法方法一:基于Redis的setnx的操作 我们在使用Redis的...
    99+
    2024-04-02
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作