redis过期键删除与内存淘汰是两套完全独立的机制:前者依据时间戳触发惰性或定期删除,与内存无关;后者在内存超限时按策略淘汰键,不关心是否过期。

Redis过期键删除策略和内存淘汰策略不是同一层机制,也不是互为补充的“双保险”,而是完全独立、触发条件与目标都不同的两套系统。混淆它们会导致配置失当、内存持续上涨甚至写入失败。
过期键删除只管“时间到了没”,不管内存剩多少
只要某个 key 设置了过期时间(比如用 EXPIRE 或 SETEX),它就会被记入数据库的 expires 字典;之后 Redis 仅依据这个时间戳判断是否该删——和当前内存使用率 used_memory 完全无关。
- 惰性删除:每次执行
GET、HGET等访问命令时,才调用expireIfNeeded()检查并同步/异步删掉已过期的key - 定期删除:每 100ms(由
hz配置决定,默认 10)随机抽样检查expires字典里的键,删掉其中已过期的部分;但不会遍历全部,也不会因内存告急而加大力度 - 没有“定时删除”:Redis 实际未采用严格定时器方案,因主线程无法承受高频定时中断,源码中也无对应实现
内存淘汰策略只管“内存超没超”,不管键有没有过期
当 used_memory ≥ maxmemory 时触发,此时 Redis 已经“喘不过气”,必须立刻腾出空间保障后续写入。它不看 expires 字典是否存在,也不等键自然到期——哪怕所有键都永不过期,只要内存爆了,照样按策略删。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
noeviction(默认):拒绝写入,报错OOM command not allowed when used memory > 'maxmemory' -
volatile-lru和allkeys-lru等策略,本质是采样 + 近似 LRU/LFU 计算,选“最该删”的键,跟过期时间戳无直接关系 - 即使一个键已过期但尚未被惰性或定期删除机制清理,它仍会参与内存淘汰的候选池(除非策略限定为
volatile-*类)
两者真正交集只有“volatile-ttl”这种特殊策略
volatile-ttl 是唯一显式依赖过期时间的淘汰策略,但它不是“先过期再淘汰”,而是把所有设置了过期时间的键拉出来,按 ttl 值升序排序,优先淘汰 ttl 最小(即“马上就要过期”)的键。注意:
- 它不等待键真正过期,也不触发惰性/定期删除逻辑
- 它只在内存不足时启动,和
expires字典的维护机制完全解耦 - 如果
maxmemory设得过大,或业务几乎不设过期时间,这个策略就基本失效
最容易被忽略的一点:过期键可能长期滞留内存——惰性删除不访问就不删,定期删除又抽不中,而内存淘汰若配成 noeviction 或 allkeys-random,根本不管它是否过期。结果就是 INFO memory 显示 used_memory_peak 居高不下,expired_keys 计数却增长缓慢。这时候得查 keyspace_hits/keyspace_misses 比值,而不是盲目调大 maxmemory。










