Redis键过期不立即释放内存，采用定期抽查与惰性检查组合策略，导致延迟释放、堆积风险及与淘汰机制耦合；大量短TTL低访问键易成“僵尸键”，加剧内存压力并干扰LRU淘汰。

Redis 键过期策略对内存使用的影响评估，核心在于理解“过期 ≠ 立即释放内存”。很多开发者误以为设置了 EXPIRE 就等于数据到期自动消失，结果在高写入、低访问场景下发现内存持续上涨，甚至触发 OOM。实际影响主要体现在三个层面：延迟释放、堆积风险、与淘汰机制的耦合。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

过期键不会立刻从内存中清除
Redis 不采用定时器逐个监听过期时间（避免 CPU 过载），而是用“定期抽查 + 惰性检查”组合策略。这意味着：

• 一个 key 到期后，只要没人读它，它就继续占着内存；
• 定期任务每 100ms 执行一次，每次只随机检查 20 个带过期时间的 key（默认配置），若这批里过期比例超 1/4，会再抽一轮——但仍有大量漏网之鱼；
• 大量短 TTL 的 key（如验证码、临时 token）若访问频次低，极易形成“僵尸键”，长期滞留。

内存占用可能远超业务预期
尤其在以下情况，内存压力会快速放大：

• 写多读少：比如批量写入带 60s TTL 的日志缓存，但后续几乎不查询，过期键堆积成片；
• TTL 设置过于集中：大量 key 统一设为 EXPIREAT 1751816400（某整点时间），导致秒级集中过期，定期删除来不及处理，内存瞬时释放滞后；
• 集群分片不均：某些节点承载了过多带 TTL 的 key，而定期删除是单节点独立执行，容易出现局部内存倾斜。

过期键堆积会间接触发内存淘汰
当 used_memory 接近 maxmemory 时，Redis 启动淘汰机制（如 allkeys-lru）。但注意：

• 淘汰策略只针对“未过期”的 key —— 已过期但尚未被清理的 key 不参与淘汰，它们白占内存却不被驱逐；
• 这会导致真正有效的热数据反而被提前淘汰，业务命中率下降；
• INFO stats 中的 expired_keys（累计删除数）和 evicted_keys（累计淘汰数）若同时持续增长，往往是过期清理滞后 + 内存吃紧的明确信号。

可观测与调优建议

• 监控关键指标：used_memory, mem_fragmentation_ratio, expired_keys, evicted_keys, keyspace_hits / keyspace_misses；
• 调整 hz 参数（默认 10）可加快定期删除频率，但会增加 CPU 开销，建议在 10–20 间谨慎试探；
• 对高频短 TTL 场景，主动分散过期时间：EXPIREAT key (now + 60 + rand(0,30))，避免雪崩；
• 避免依赖过期做精确时效控制（如订单关闭），应配合外部定时任务或 Redis Streams + consumer group 做可靠延迟处理。