文档教程知识库【免费下载链接】CS-Base图解计算机网络、操作系统、计算机组成、数据库共 1000 张图 50 万字破除晦涩难懂的计算机基础知识让天下没有难懂的八股文 在线阅读https://xiaolincoding.com项目地址https://gitcode.com/GitHub_Trending/cs/CS-Base点击查看免费下载过期删除策略与内存淘汰策略是 Redis 中两个最容易被混淆的内存治理机制——它们虽然都做删除操作但触发条件、删除对象和设计目标完全不同。本文以 CS-Base 仓库中的 redis/module/strategy.md 为骨架结合仓库内面试篇与缓存篇的佐证系统讲清二者的区别、Redis 底层源码实现过期字典、expireIfNeeded、activeExpireCycle、8 种内存淘汰策略的分类以及 LRU/LFU 两种算法的设计取舍与配置调优读完即可在面试与生产配置中准确运用。一、先分清两个概念过期删除 vs 内存淘汰在深入细节之前先明确两个机制的本质区别过期删除策略处理的是已经过期的 key。Redis 允许对 key 设置过期时间当 key 到期后需要有机制把它从内存中删除负责这项工作的是过期键删除策略。内存淘汰策略处理的是内存不足的问题。当 Redis 的运行内存达到设定的maxmemory上限时需要按策略淘汰一些 key 来腾出空间保证 Redis 高效运行。一句话概括过期删除解决键过期了没人清理内存淘汰解决内存满了放不下新数据。两者是独立的机制但生产环境中往往协同生效。二、过期删除策略Expiration2.1 如何给 key 设置过期时间设置 key 过期时间的命令一共有 4 个分别支持秒级与毫秒级、相对时间与绝对时间命令含义示例expire key n设置 key 在 n秒后过期expire key 100表示 key 在 100 秒后过期pexpire key n设置 key 在 n毫秒后过期pexpire key2 100000表示 key2 在 100000 毫秒100 秒后过期expireat key n设置 key 在某个时间戳精确到秒之后过期expireat key3 1655654400表示 key3 在该时间戳后过期pexpireat key n设置 key 在某个时间戳精确到毫秒之后过期pexpireat key4 1655654400000表示 key4 在该时间戳后过期此外在设置字符串键值对时也可以同时指定过期时间共有 3 种命令set key value ex n设置键值对时指定过期时间精确到秒set key value px n设置键值对时指定过期时间精确到毫秒setex key n value设置键值对时指定过期时间精确到秒。查看剩余存活时间使用TTL key命令返回值为剩余秒数# 设置键值对的时候同时指定过期时间为 60 秒 setex key1 60 value1 OK # 查看 key1 过期时间还剩多少 ttl key1 (integer) 56 ttl key1 (integer) 52取消过期时间如果反悔了用PERSIST key命令去掉过期时间# 取消 key1 的过期时间 persist key1 (integer) 1 # 使用完 persist 命令之后 # 查下 key1 的存活时间结果是 -1表明 key1 永不过期 ttl key1 (integer) -1注意 TTL 的返回语义-1表示 key 永不过期未设置过期时间-2表示 key 已不存在正数表示剩余存活秒数。2.2 如何判定 key 已过期——过期字典expires dict每当我们对一个 key 设置过期时间时Redis 会把该 key 连同过期时间一起存储到一个过期字典expires dict中也就是说过期字典保存了数据库中所有 key 的过期时间。过期字典存储在redisDb结构中源码结构示意见 redis/module/strategy.mdtypedef struct redisDb { dict *dict; /* 数据库键空间存放着所有的键值对 */ dict *expires; /* 键的过期时间 */ .... } redisDb;过期字典本身的数据结构要点过期字典的key 是一个指针指向某个键对象过期字典的value 是一个 long long 类型的整数保存了该 key 的过期时间。字典本质上是一个哈希表哈希表的最大好处是可以用O(1) 的时间复杂度快速查找。因此当我们查询一个 key 时Redis 会先检查该 key 是否存在于过期字典中如果不在过期字典中正常读取键值如果在过期字典中获取该 key 的过期时间与当前系统时间比对——如果过期时间比系统时间大说明未过期正常返回否则判定该 key 已过期走删除流程。这个查过期字典 → 比对时间 → 判定过期的过程就是过期键判定的核心逻辑。2.3 三种经典的过期删除策略对比在说 Redis 具体采用哪种策略之前先了解通用的三种过期删除策略各自都有鲜明的优缺点① 定时删除Timer-based做法在设置 key 的过期时间时同时创建一个定时事件当时间到达时由事件处理器自动执行 key 的删除操作。优点可以保证过期 key 被尽快删除内存被尽快释放因此对内存最友好缺点在过期 key 比较多的情况下删除过期 key 会占用相当一部分 CPU 时间。在内存不紧张但 CPU 紧张时把 CPU 时间用于删除与当前任务无关的过期键会严重影响服务器的响应时间和吞吐量因此对 CPU 不友好。② 惰性删除Lazy做法不主动删除过期键每次从数据库访问 key 时才检测 key 是否过期过期则删除该 key。优点因为每次访问时才检查所以此策略只会使用很少的系统资源对 CPU 时间最友好缺点如果一个 key 已经过期却一直保留在数据库中只要它一直没被访问所占用的内存就不会释放造成内存浪费因此对内存不友好。③ 定期删除Periodic做法每隔一段时间「随机」从数据库中取出一定数量的 key 进行检查并删除其中的过期 key。优点通过限制删除操作执行的时长和频率减少删除操作对 CPU 的影响同时也能删除一部分过期数据减少过期键对空间的无效占用缺点内存清理方面没有定时删除效果好同时没有惰性删除使用的系统资源少而且难以确定删除操作的执行时长和频率——执行得太频繁就退化成像定时删除一样对 CPU 不友好执行得太少又和惰性删除一样过期 key 占用的内存得不到及时释放。三种策略各有侧重定时删除重内存轻 CPU惰性删除重 CPU 轻内存定期删除是二者的折中但难以拿捏尺度。2.4 Redis 的选择惰性删除 定期删除仅使用任何一种策略都无法满足实际需求所以Redis 选择「惰性删除 定期删除」两种策略配合使用以求在合理使用 CPU 时间和避免内存浪费之间取得平衡。2.4.1 惰性删除的源码实现expireIfNeeded函数Redis 的惰性删除策略由 db.c 文件中的expireIfNeeded函数实现代码摘录自 redis/module/strategy.mdint expireIfNeeded(redisDb *db, robj *key) { // 判断 key 是否过期 if (!keyIsExpired(db,key)) return 0; .... /* 删除过期键 */ .... // 如果 server.lazyfree_lazy_expire 为 1 表示异步删除反之同步删除 return server.lazyfree_lazy_expire ? dbAsyncDelete(db,key) : dbSyncDelete(db,key); }Redis 在访问或者修改 key 之前都会调用expireIfNeeded函数对其进行检查如果 key 已过期则删除该 key——至于选择异步删除还是同步删除由lazyfree-lazy-expire参数配置决定该参数从Redis 4.0版本开始提供然后返回 null 给客户端如果没有过期不做任何处理返回正常的键值对给客户端。这里体现了一个重要的设计细节删除动作不一定是同步阻塞的。从 Redis 4.0 引入 lazy free 机制后可以把过期键的删除交给后台线程异步完成避免在主线程上释放大对象造成阻塞相关内容在 redis/base/redis_interview.md 的后台线程小节有详细展开。2.4.2 定期删除的源码实现activeExpireCycle函数再回顾定期删除的做法每隔一段时间「随机」从数据库中取出一定数量的 key 进行检查并删除其中的过期 key。① 间隔检查的时间是多长在 Redis 中默认每秒进行 10 次过期检查这个频率可通过配置文件 redis.conf 的hz参数调整hz默认值是10。需要特别强调的是每次检查并不是遍历过期字典中的所有 key而是从数据库中随机抽取一定数量的 key 进行过期检查。② 随机抽查的数量是多少定期删除的实现在 expire.c 文件下的activeExpireCycle函数中随机抽查的数量由ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP常量定义它是写死在代码中的数值是 20。也就是说数据库每轮抽查时会随机选择 20 个 key 判断是否过期。③ 定期删除的完整流程从过期字典中随机抽取 20 个 key检查这 20 个 key 是否过期并删除已过期的 key如果本轮检查的已过期 key 数量超过 5 个20/4即「已过期 key 的数量」占「随机抽取 key 的数量」大于 25%则继续重复步骤 1如果已过期的 key 比例小于 25%则停止本轮删除等待下一轮再检查。可以看到定期删除是一个循环流程。为了保证定期删除不会循环过度导致线程卡死Redis 为定期删除循环流程增加了时间上限默认不会超过 25ms。针对这个流程原文档给出了一段精炼的伪代码可以对照理解do { //已过期的数量 expired 0 //随机抽取的数量 num 20; while (num--) { //1. 从过期字典中随机抽取 1 个 key //2. 判断该 key 是否过期如果已过期则进行删除同时对 expired } // 超过时间限制则退出 if (timelimit_exit) return; /* 如果本轮检查的已过期 key 的数量超过 25%则继续随机抽查否则退出本轮检查 */ } while (expired 20/4);整个机制的巧妙之处在于25% 的过期率阈值 25ms 的时间上限双保险——既能在过期 key 密集时持续清理又不会因为清理而长时间占用主线程。2.5 纵深补充过期键在持久化与主从复制中的处理理解了删除机制后还有一个高频面试考点过期键在 RDB/AOF 持久化以及主从复制中如何处理仓库的 redis/base/redis_interview.md 给出了完整答案这里一并归纳。RDB 文件的生成与加载阶段RDB 文件生成阶段从内存状态持久化成 RDB 文件时会对 key 进行过期检查过期的键不会被保存到新的 RDB 文件中RDB 文件加载阶段分主从两种模式——若 Redis 是主服务器运行模式载入 RDB 文件时程序会对文件中的键进行检查过期键不会被载入数据库若 Redis 是从服务器运行模式载入 RDB 文件时不论键是否过期都会载入。但由于主从同步时从服务器的数据会被清空所以一般不会造成影响。AOF 文件的写入与重写阶段AOF 文件写入阶段如果数据库某个过期键还没被删除AOF 文件会保留此过期键当此过期键被删除后Redis 会向 AOF 文件追加一条DEL 命令来显式删除该键值AOF 重写阶段执行 AOF 重写时会对键值对进行检查已过期的键不会被保存到重写后的 AOF 文件中。主从模式中的过期键处理从库不会进行过期扫描对过期的处理是被动的。也就是说即使从库中的 key 已过期客户端访问从库时依然能拿到值像未过期一样返回从库的过期键处理由主服务器控制主库在 key 到期时会在 AOF 文件里增加一条 DEL 指令并同步到所有从库从库通过执行这条 DEL 指令来删除过期的 key。这解释了为什么主从模式下读从库可能读到已过期的数据——因为它依赖主库推送的 DEL 命令存在同步时差。相关实现细节可继续阅读 redis/base/redis_interview.md 与 redis/storage/rdb.md、redis/storage/aof.md。三、内存淘汰策略Eviction前面说的过期删除策略删除的是已过期的 key而当 Redis 的运行内存超过设置的最大内存之后则会使用内存淘汰策略删除符合条件的 key以此保障 Redis 高效运行。3.1 如何设置 Redis 最大运行内存在配置文件 redis.conf 中通过参数maxmemory bytes设定最大运行内存。只有 Redis 的运行内存达到设定的最大运行内存才会触发内存淘汰策略。不同位数的操作系统maxmemory的默认值不同64 位操作系统maxmemory默认值是0表示没有内存大小限制。这种情况下不管存放多少数据Redis 都不会对可用内存进行检查直到 Redis 实例因内存不足而崩溃也无作为32 位操作系统maxmemory默认值是3G。因为 32 位机器最大只支持 4GB 内存而系统本身就需要一定内存资源维持运行所以限制最大 3GB 可用内存是合理的可避免因内存不足导致 Redis 实例崩溃。3.2 Redis 内存淘汰策略有哪些——八种策略全览Redis 内存淘汰策略共有8 种大体分为「不进行数据淘汰」和「进行数据淘汰」两类。① 不进行数据淘汰的策略noevictionRedis 3.0 之后的默认策略当运行内存超过最大设置内存时不淘汰任何数据。此时如果有新的数据写入会触发 OOM但如果只是单纯的查询或删除操作仍可正常工作。② 进行数据淘汰的策略又细分为「在设置了过期时间的数据中进行淘汰」和「在所有数据范围内进行淘汰」两类。在设置了过期时间的数据中进行淘汰策略说明volatile-random随机淘汰设置了过期时间的任意键值volatile-ttl优先淘汰更早过期的键值volatile-lruRedis 3.0 之前默认策略淘汰所有设置了过期时间的键值中最久未使用的键值volatile-lfuRedis 4.0 后新增淘汰所有设置了过期时间的键值中最少使用的键值在所有数据范围内进行淘汰策略说明allkeys-random随机淘汰任意键值allkeys-lru淘汰整个键值中最久未使用的键值allkeys-lfuRedis 4.0 后新增淘汰整个键值中最少使用的键值一个容易忽略的细节volatile-*系列策略只针对设置了过期时间的 key如果没有任何 key 设置过期时间那么这些策略在内存满时同样无法淘汰数据效果退化为不淘汰。因此若业务主要靠 TTL 管理缓存建议结合数据特征选择合适的策略。3.3 如何查看与修改内存淘汰策略查看当前策略使用config get maxmemory-policy命令127.0.0.1:6379 config get maxmemory-policy 1) maxmemory-policy 2) noeviction可以看到当前 Redis 使用的是noeviction策略——这也是 Redis 3.0 之后的默认策略表示运行内存超过最大设置内存时不淘汰任何数据但新增操作会报错。修改策略有两种方式方式一运行时命令——config set maxmemory-policy 策略。优点是立即生效无需重启缺点是重启 Redis 后设置失效方式二修改配置文件——在 redis.conf 中设置maxmemory-policy 策略。优点是重启后配置不丢失缺点是必须重启 Redis 服务才能生效。生产环境推荐组合拳先用config set在线切换观察效果确认无误后再同步修改配置文件避免重启回退。四、LRU 与 LFURedis 的两种主要淘汰算法LFU 内存淘汰算法是 Redis 4.0 之后新增的为什么要新增就是为了解决 LRU 算法存在的问题。这一节深入对比两者的设计取舍与 Redis 的实现方式。4.1 传统 LRU 算法及其问题LRU全称 Least Recently Used译为最近最少使用选择淘汰最近最少使用的数据。传统 LRU 算法基于链表结构实现链表中的元素按操作顺序从前往后排列最新操作的键会被移动到表头需要内存淘汰时只需删除链表尾部的元素即可因为链表尾部代表最久未被使用的元素。Redis 没有采用这种方式因为传统 LRU 算法存在两个问题需要用链表管理所有缓存数据带来额外的空间开销有数据被访问时需要在链表上移动该项到头部当大量数据被访问时会产生大量链表移动操作非常耗时进而降低 Redis 缓存性能。4.2 Redis 的近似 LRU 实现Redis 实现的是一种近似 LRU 算法目的是更好地节约内存。实现方式是在 Redis 的对象结构体中添加一个额外的字段用于记录此数据的最后一次访问时间。当 Redis 进行内存淘汰时使用随机采样的方式来淘汰数据随机取 5 个值此值可配置淘汰其中最久没有使用的那一个。Redis 近似 LRU 的优点不用为所有数据维护一个大链表节省了空间占用不用在每次数据访问时都移动链表项提升了缓存性能。但 LRU 算法有一个致命问题——无法解决缓存污染问题比如应用一次性读取了大量数据而这些数据只会被读取这一次那么这些数据会长时间留存在 Redis 缓存中造成缓存污染。这正是 Redis 4.0 之后引入 LFU 算法的原因。4.3 LFU 算法按访问频率淘汰LFU全称 Least Frequently Used译为最近最不常用。LFU 算法根据数据访问次数来淘汰数据核心思想是如果数据过去被访问多次那么将来被访问的频率也更高。所以 LFU 会记录每个数据的访问次数当一个数据被再次访问时就增加其访问次数从而解决偶尔被访问一次的数据长期占用缓存的问题相比 LRU 更合理。Redis 如何实现 LFU——lru字段的位级复用LFU 相比 LRU 的实现多记录了「数据的访问频次」信息。Redis 对象的结构如下摘录自 redis/module/strategy.mdtypedef struct redisObject { ... // 24 bits用于记录对象的访问信息 unsigned lru:24; ... } robj;Redis 对象头中的lru字段24 bits在 LRU 算法下和 LFU 算法下的使用方式并不相同在 LRU 算法中24 bits 的lru字段记录的是 key 的访问时间戳。LRU 模式下Redis 根据该字段比较 key 的最后访问时间淘汰最久未被使用的 key在 LFU 算法中24 bits 的lru字段被分成两段存储——高16 bit存储ldtLast Decrement Time低8 bit存储logcLogistic Counterldt用来记录 key 的访问时间戳logc用来记录 key 的访问频次值越小表示使用频率越低、越容易被淘汰每个新加入的 key 的 logc 初始值为 5。logc 的衰减与增长为什么是频次而非次数注意logc并不是单纯的访问次数而是访问频次访问频率因为logc 会随时间推移而衰减。在每次 key 被访问时会先对 logc 做衰减操作衰减的值跟前后访问时间的差距有关——如果上一次访问与这一次访问的时间差距很大那么衰减的值就越大。这样实现的 LFU 是根据访问频率淘汰数据而不只是访问次数访问频率需要考虑 key 的访问是在多长的时间段内发生的。key 的先前访问距离当前时间越长其访问频率越低被淘汰的概率也就越大。对 logc 做完衰减操作后再对 logc 进行增加操作。增加操作并不是单纯的 1而是根据概率增加——logc 越大的 key其 logc 就越难再增加。所以Redis 访问 key 时 logc 的变化过程是先按照上次访问距离当前的时长对 logc 进行衰减然后再按照一定概率增加logc 的值。redis.conf 提供了两个配置项用于调整 LFU 算法的 logc 增长与衰减lfu-decay-time调整 logc 的衰减速度以分钟为单位的数值默认值为1。值越大衰减越慢lfu-log-factor调整 logc 的增长速度值越大logc 增长越慢。这两个参数是 LFU 场景下真正需要调优的旋钮lfu-decay-time决定多久不访问就降温lfu-log-factor决定访问多少次才能升温配合业务访问模型可以控制热点数据的留存时长。4.4 纵深补充淘汰与 lazy free 异步删除的联动配置内存淘汰触发删除时同样面临删除大 key 阻塞主线程的风险。仓库 redis/base/redis_interview.md 指出从 Redis 4.0 开始可以通过 lazy free 配置让某些场景的删除异步化相关配置项默认都是关闭的lazyfree-lazy-eviction no lazyfree-lazy-expire no lazyfree-lazy-server-del no noslave-lazy-flush no它们各自的含义lazyfree-lazy-eviction当 Redis 运行内存超过 maxmemory 触发内存淘汰时是否开启 lazy free 机制删除lazyfree-lazy-expire设置了过期时间的键值当过期之后是否开启 lazy free 机制删除与上文expireIfNeeded函数中的server.lazyfree_lazy_expire直接对应lazyfree-lazy-server-del某些指令在处理已存在的键时会带隐式的 DEL 操作如rename命令覆盖目标键如果目标键是 big key 会造成阻塞删除此配置表示这种场景是否开启 lazy freenoslave-lazy-flush从节点进行全量同步、加载主节点 RDB 文件前会执行flushall清理自身数据此配置表示此时是否开启 lazy free。建议开启其中的lazyfree-lazy-eviction、lazyfree-lazy-expire、lazyfree-lazy-server-del等配置可以有效提高主线程的执行效率——这组配置正是把过期删除 内存淘汰从主线程同步删除升级为后台异步删除的关键开关体现了 Redis 4.0 之后对删除操作的整体性能优化思路。五、实战视角过期时间与缓存问题的关联理解了过期删除机制后就能解释缓存场景中最常见的缓存雪崩问题。仓库 redis/cluster/cache_problem.md 指出当大量缓存数据在同一时间过期失效时大量用户请求都无法在 Redis 中命中全部涌向数据库导致数据库压力骤增甚至宕机这就是缓存雪崩。应对大量数据同时过期这一诱因核心手段就是均匀设置过期时间给缓存数据设置过期时间时加上一个随机数比如在原失效时间基础上加 110 分钟保证数据不会在同一时间过期。这与本文讨论的过期字典、定期删除机制直接相关——同一时刻过期的 key 越多定期删除每轮抽查的过期率越容易超过 25% 阈值持续清理的轮次也就越多。其它配套方案还包括互斥锁保证同一时间只有一个请求重建缓存、双 key 策略主 key 过期时直接返回备 key、后台更新缓存缓存永久有效但由后台定时刷新等完整方案可继续阅读 redis/cluster/cache_problem.md。总结一张表理清两大机制对比维度过期删除策略内存淘汰策略触发条件key 到达设置的过期时间Redis 运行内存超过maxmemory上限删除对象已过期的 key符合条件的任意 key或过期 key取决于策略核心实现惰性删除expireIfNeeded 定期删除activeExpireCyclemaxmemory-policy指定的 8 种策略之一关键配置hz、ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP、lazyfree-lazy-expiremaxmemory、maxmemory-policy、lazyfree-lazy-eviction设计目标及时回收过期键在 CPU 开销与内存浪费间平衡内存超限时保障 Redis 稳定运行核心结论Redis 使用的过期删除策略是「惰性删除 定期删除」删除的对象是已过期的 key内存淘汰策略解决内存过大的问题当运行内存超过最大运行内存时触发Redis 4.0 之后共实现了8 种内存淘汰策略两者可以叠加生效过期 key 由过期删除策略回收而内存仍不足时再由内存淘汰策略兜底LRU 侧重最近未使用LFU 侧重访问频率低Redis 均以近似算法 随机采样实现兼顾空间与性能。下次再被问到过期删除和内存淘汰有什么区别抓住两个关键词就不会混淆一个是清过期一个是腾内存。想系统学习 Redis 其他主题可以继续阅读仓库中的 redis/README.md 导航或深入 redis/base/redis_interview.md40 面试题与 redis/storage/bigkey_aof_rdb.md大 key 对持久化的影响等专题。赞分享文档教程知识库【免费下载链接】CS-Base图解计算机网络、操作系统、计算机组成、数据库共 1000 张图 50 万字破除晦涩难懂的计算机基础知识让天下没有难懂的八股文 在线阅读https://xiaolincoding.com项目地址https://gitcode.com/GitHub_Trending/cs/CS-Base点击查看免费下载相关推荐Redis 过期策略与内存淘汰机制全解析定期删除、惰性删除与手写 LRU 实战Redis 过期策略与内存淘汰机制全解析定期删除、惰性删除与手写 LRU 实战 Redis 是高性能缓存的代名词但写进去的数据为什么会凭空消失明明设置文档教程知识库后端Redis 过期策略与 LRU 算法深度解析定期删除 惰性删除与内存淘汰机制实战doocs/advanced-java 高并发缓存篇Redis 过期策略与 LRU 算法深度解析定期删除 惰性删除与内存淘汰机制实战doocs/advanced java 高并发缓存篇 Redis 是互文档教程后端jeecg-boot分布式缓存Redis过期策略与内存淘汰机制深度解析jeecg boot分布式缓存Redis过期策略与内存淘汰机制深度解析 jeecg boot作为一款优秀的企业级快速开发平台其分布式缓存机制在系统性能优化中低代码后端前端AI 应用大模型RAG工作流自动化上一篇Claw Code开发者指南如何贡献代码和参与开源项目下一篇AWS Doc SDK Examples 的 Ailly 工作流中的 P 阶段如何 Prepare 一个精确且有目的性的提示词创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考