大白话看明白Redis数据淘汰策略，渣男提裤不认人

最新推荐文章于 2025-04-22 18:10:36 发布

石添的编程哲学

最新推荐文章于 2025-04-22 18:10:36 发布

阅读量1.8k

点赞数 9

分类专栏： Redis系列文章标签： redis Redis数据淘汰策略数据淘汰

本文链接：https://blog.csdn.net/qq_36386908/article/details/106298472

版权

Redis系列专栏收录该内容

9 篇文章

订阅专栏

点赞多大胆，就有多大产！开源促使进步，献给每一位技术使用者和爱好者！
干货满满，摆好姿势，点赞发车

Redis数据淘汰策略

前言

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

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

内存配置

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

在这里插入图片描述
上图是Redis5.0.5版本的配置，默认是被注释掉关闭的，单位是字节，当设置为0时没有限制

淘汰策略

Redis4之后为我们提供了八个不同的内存置换策略。之前版本提供了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策略可以保证数据不被丢失。

这八种大体上可以分为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的优化策略，分别是REWRITEAOF和BGREWRITEAOF，两个命令的区别也是在于是否阻塞主进程，这两个命令都不会将数据空间中的过期键给保存到AOF文件中；

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

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

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