百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术教程 > 正文

大白话讲清楚Redis数据淘汰策略(redis淘汰策略的参数配置)

mhr18 2024-11-11 12:00 15 浏览 0 评论

满怀忧思,不如先干再说!持续高频更新技术文章,赶紧关注吧!

本文章为系列文章,本篇文章讲解面试高频知识点:Redis数据淘汰策略,如希望了解Redis使用方式请滑到文末,移步合集列表。

Redis数据淘汰策略

前言

Redis作为一个内存数据库,性能十分高,主要依赖的硬件资源就是内存,据官方数据表示Redis读的速度是110000次/s,写的速度是81000次/s,我们向Redis中源源不断存储数据,内存空间有限,这时淘汰无用数据释放空间,存储新数据就变得尤为重要,Redis提供了数据淘汰策略来释放内存

内容偏向理论,需要大家发挥想象脑补画面,最好记下来,成为面试时的谈资

内存配置

Redis在生产环境中,采用配置参数maxmemory 的方式来限制内存大小。当实际存储内存超出maxmemory 参数值时,可以通过Redis内存淘汰策略,来决定如何腾出新空间继续支持读写工作

上图是Redis5.0.5版本的配置,默认是被注释掉关闭的,单位是字节,当设置为0时没有限制

淘汰策略

Redis4之后为我们提供8种内存置换策略。之前版本提供了6种

  • volatile-lru:从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰。没有设置过期时间的key不会被淘汰,这样就可以在增加内存空间的同时保证需要持久化的数据不会丢失
  • volatile-ttl:从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰。
  • volatile-random:从已设置过期时间的数据集(server.db[i].expires)中任意选择数据淘汰。
  • volatile-lfu:从已设置过期时间的数据集(server.db[i].expires)挑选使用频率最低的数据淘汰。
  • allkeys-lru:从数据集(server.db[i].dict)中挑选最近最少使用的数据淘汰
  • allkeys-lfu:从数据集(server.db[i].dict)中挑选使用频率最低的数据淘汰。
  • allkeys-random:从数据集(server.db[i].dict)中任意选择数据淘汰
  • no-enviction(驱逐):禁止驱逐数据,这也是默认策略。意思是当内存不足以容纳新入数据时,新写入操作就会报错,请求可以继续进行,线上任务也不能持续进行,采用no-enviction策略可以保证数据不被丢失。

8种大体上可以分为4类,lru、lfu、random、ttl,其中lfu方式是新增策略,也就是根据使用率来淘汰数据

通过设置maxmemory-policy设置淘汰策略

Redis是怎么触发淘汰机制的呢

首先,客户端存储数据,肯定需要有内存来存储

其次,Redis检查内存使用情况,如果实际使用内存已经超出maxmemory,Redis就会根据用户配置的淘汰策略选出无用的key

最后,确认选中数据没有问题,成功执行淘汰任务

过期键删除策略

我们都知道Redis中的key是可以设置过期时间的,这里提一下怎么判定过期键

  • Redis键的过期时间都保存在过期字典中
  • 检查给定键是否存在于字典中,如果有取得键的过期时间
  • 检查当前UNIX时间戳是否大于键的过期时间,如果是的话那么该键已经过期,否则键未过期

接下来我们就说说过期的key如何被无情抛弃的

定时删除

  • 在设置键的过期时间的同时,创建一个定时器(timer),让定时器在键的过期时间来临时,立即执行对键的删除操作;
  • 定时删除操作对于内存来说是友好的,通过使用定时器,可以保证尽快的将过期键删除,释放所占内存
  • 对于CPU来说不是友好的,如果过期键比较多的话,删除过期键这一行为可能占用相当一部分CPU时间,在内存不紧张但是CPU紧张的情况下,将CPU时间用在删除和当前任务无关的过期键上,无疑会对服务器的响应时间和吞吐量造成影响,在某些情况下有点分不清主次啦!
  • 例如:如果有大量的命令请求等待服务器处理,并且服务器当前不缺少内存,那么服务器应该优先将CPU时间用在处理客户端的请求上,而不是删除过期键上面
  • 创建一个定时器需要用到Redis服务器中的事件事件,当前时间事件的实现方式是无序链表,查找一个事件的时间复杂度为O(N),并不能高效处理大量时间事件
  • 因此要让服务器创建大量的定时器,从而实现定时策略删除,在这里是不现实的

惰性删除

  • 对CPU是友好的,程序只会在取出键时才对键进行过期检查,这可以保证删除过期键的操作只会在非做不可时进行,并且删除的目标仅限于当前处理的键,这个策略不会在删除其他无关的过期建上浪费任何CPU时间
  • 对内存是不友好的,如果一个键已经过期,而这个键仍然保留在数据库中,那么只要这个过期键不被删除,它所占的内存就不会释放
  • 在使用惰性删除策略时,如果数据库中有非常多的过期键,而这些过期建又恰好没有被访问到的话,那么它们也许永远也不会被删除(除非用户手动执行FLUSHDB或者FLUSHALL,谨慎别用,企业中一般会将这连个命令禁用甚至删除掉,劲太猛了),这种情况是不是就是我们程序中说的内存泄漏,无用的数据占用大量内存,对于Redis这种内存数据库来说肯定不是好事
  • 例如:对于一些和时间有关的数据,比如日志(log),在某个时间点之后,对它们的访问就会减少,甚至不再访问,如果这类过期数据大量的积压在数据库中,用户以为服务器已经将它们删除了,但实际还存在,而且键所占内存也没有释放,会造成很严重的后果

定期删除

  • 上边两种删除策略在单一使用时都有明显的缺陷,定时删除占用太多CU时间,降低服务器吞吐量和响应时间,惰性删除浪费太多内存,有内存泄漏危险,定期删除就是前两种策略的整合和折中方案
  • 定期删除策略每隔一段时间执行一次删除过期键操作,并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响
  • 通过定期删除过期键,定期删除策略有效地减少因过期键带来的内存浪费

定期删除策略的难点在于确定删除操作的时长和频率

  • 如果删除处操作执行的太频繁,或者执行的时间太长(时间长不一定好),定时删除策略不就退化成定时删除策略了嘛,以至于CPU将过多的时间耗费在删除粗过期键上
  • 如果删除处理执行的太少,或者时间太短~~~,定期删除策略又会向惰性删除那样,出现内存浪费情况
  • 因此采用定期删除策略,服务器必须根据情况,设置删除操作的执行时长和执行频率

Redis服务器实际使用的删除策略是惰性删除和定时删除两种,相互配合可以在CPU使用时间和内存空间取得平衡。具体代码实现暂不讨论,有兴趣的可以翻阅源码

AOF、RDB和复制功能对过期键处理

RDB

生成RDB文件

执行SAVE或者BGSAVE创建新的RDB文件时,程序会对数据库中的键进行检查,已过期的键不会被保存到新创建的RDB文件中,因此数据库包含过期键不会对新的RDB文件造成影响

载入RDB文件

在启动Redis服务器时,如果服务器开启了RDB文件,那么服务器就会对RDB文件进行载入

  • 如果当前服务器是Master,程序会对文件中保存的key进行检查,未过期的键会被载入到数据库中,而过期的键则会被忽略,所以过期键对载入RDB文件的主服务器不会造成影响
  • 如果当前服务器是Slave,文件中保存的所有键,无论是否过期,都会被载入到数据库中,不过,因为主从服务器在进行数据同步时,从服务器的数据库就会被同步成和主服务器一致,所以一般来讲,过期键对载入RDB文件的从服务器也不会造成影响
  • 例如:数据库中有k1, k2, k3三个键,k2已经过期,启动服务时
  • 如果是主服务器,k1, k3会被载入,k2会被忽略
  • 如果是从服务器,k1, k2, k3都会被载入

AOF

AOF文件写入

当服务器以AOF持久化模式运行时,如果数据库中的某个key已经过期,但是他还没有被惰性删除或者定期删除,那么AOF文件不会因为这个过期键产生任何影响,当该键被惰性删除或者定期删除之后,程序会向AOF文件追加一条DEL命令,来显式记录该键已被删除

  • 试图获取过期键zhishi,会有以下三个动作:
  • 从数据库中删除zhishi
  • 追加一条DEL zhishi命令到AOF文件
  • 向执行 GET命令的客户端返回空回复

AOF重写

AOF是将执行的写命令添加到AOF文件的末尾来记录数据的变化;为了避免文件被添加得越来越大,甚至有可能用完硬盘的所有空间,因此Redis提供了Rewrite的优化策略,分别是REWRITEAOFBGREWRITEAOF,两个命令的区别也是在于是否阻塞主进程,这两个命令都不会将数据空间中的过期键给保存到AOF文件中

主从复模式下对过期键的处理

复制模式下,从服务器的过期键删除动作由主服务控制

  • 主服务器在删除一个过期键之后,会显式地向所有从服务器发送一个DEL命令,告知从服务器删除这个过期键
  • 从服务器在执行客户端发送过来的读命令时,即使碰到过期键也不会删除,而是继续向处理未过期键一样来处理过期键
  • 从服务器只有接收到主服务器发送过来的DEL命令之后,才会删除过期键
  • 通过由主服务器来控制从服务器统一地删除过期键,可以保证主从服务器数据一致性,也正是因为这个原因,当一个过期键仍然存在于主服务器时,这个过期键在从服务器中的复制品也会继续存在

本文参考

  • 《Redis设计与实现》

相关推荐

Spring Boot3 连接 Redis 竟有这么多实用方式

各位互联网大厂的后端开发精英们,在日常开发中,想必大家都面临过系统性能优化的挑战。当系统数据量逐渐增大、并发请求不断增多时,如何提升系统的响应速度和稳定性,成为了我们必须攻克的难题。而Redis,这...

隧道 ssh -L 命令总结 和 windows端口转发配置

摘要:隧道ssh-L命令总结和windows端口转发配置关键词:隧道、ssh-L、端口转发、网络映射整体说明最近在项目中,因为内网的安全密级比较高,只能有一台机器连接内网数据库,推送...

火爆BOOS直聘的13个大厂Java社招面经(5年经验)助你狂拿offer

火爆BOOS直聘的13个大厂Java社招面经(5年经验)助你狂拿offer综上所述,面试遇到的所有问题,整理成了一份文档,希望大家能够喜欢!!Java面试题分享(Java中高级核心知识全面解析)一、J...

「第五期」游服务器一二三面 秋招 米哈游

一面下午2点,35分钟golang内存模型golang并发模型golanggc原理过程channel用途,原理redis数据结构,底层实现跳跃表查询插入复杂度进程,线程,协程kill原理除了kil...

RMQ——支持合并和优先级的消息队列

业务背景在一个项目中需要实现一个功能,商品价格发生变化时将商品价格打印在商品主图上面,那么需要在价格发生变动的时候触发合成一张带价格的图片,每一次触发合图时计算价格都是获取当前最新的价格。上游价格变化...

Redis 中的 zset 为什么要用跳跃表,而不是B+ Tree 呢?

Redis中的有序集合使用的是一种叫做跳跃表(SkipList)的数据结构来实现,而不是使用B+Tree。本文将介绍为什么Redis中使用跳跃表来实现有序集合,而不是B+Tree,并且探讨跳跃表...

一文让你彻底搞懂 WebSocket 的原理

作者:木木匠转发链接:https://juejin.im/post/5c693a4f51882561fb1db0ff一、概述上一篇文章《图文深入http三次握手核心问题【思维导图】》我们分析了简单的一...

Redis与Java整合的最佳实践

Redis与Java整合的最佳实践在这个数字化时代,数据处理速度决定了企业的竞争力。Redis作为一款高性能的内存数据库,以其卓越的速度和丰富的数据结构,成为Java开发者的重要伙伴。本文将带你深入了...

Docker与Redis:轻松部署和管理你的Redis实例

在高速发展的云计算时代,应用程序的部署和管理变得越来越复杂。面对各种操作系统、依赖库和环境差异,开发者常常陷入“在我机器上能跑”的泥潭。然而,容器化技术的兴起,尤其是Docker的普及,彻底改变了这一...

Java开发中的缓存策略:让程序飞得更快

Java开发中的缓存策略:让程序飞得更快缓存是什么?首先,让我们来聊聊什么是缓存。简单来说,缓存是一种存储机制,它将数据保存在更快速的存储介质中,以便后续使用时能够更快地访问。比如,当你打开一个网页时...

国庆临近,字节后端开发3+4面,终于拿到秋招第一个offer

字节跳动,先面了data部门,3面技术面之后hr说需要实习转正,拒绝,之后另一个部门捞起,四面技术面,已oc分享面经,希望对大家有所帮助,秋招顺利在文末分享了我为金九银十准备的备战资源库,包含了源码笔...

“快”就一个字!Redis凭什么能让你的APP快到飞起?

咱们今天就来聊一个字——“快”!在这个信息爆炸、耐心越来越稀缺的时代,谁不希望自己手机里的APP点一下“嗖”就打开,刷一下“唰”就更新?谁要是敢让咱用户盯着个小圈圈干等,那简直就是在“劝退”!而说到让...

双十一秒杀,为何总能抢到?Redis功不可没!

一年一度的双十一“剁手节”,那场面,简直比春运抢票还刺激!零点的钟声一敲响,亿万个手指头在屏幕上疯狂戳戳戳,眼睛瞪得像铜铃,就为了抢到那个心心念念的半价商品、限量版宝贝。你有没有发现一个奇怪的现象?明...

后端开发必看!为什么说Redis是天然的幂等性?

你在做后端开发的时候,有没有遇到过这样的困扰:高并发场景下,同一个操作重复执行多次,导致数据混乱、业务逻辑出错?别担心,很多同行都踩过这个坑。某电商平台就曾因订单创建接口在高并发时不具备幂等性,用户多...

开发一个app需要哪些技术和工具

APP开发需要一系列技术和工具的支持,以下是对这些技术的清晰归纳和分点表示:一、前端开发技术HTML用于构建页面结构。CSS用于样式设计和布局。JavaScript用于页面交互和逻辑处理。React...

取消回复欢迎 发表评论: