Redis自动清理废数据方法解析

Redis的volatile-lru淘汰策略并非万能自动清道夫，而是一个精准、需主动配合的内存守门员：它只作用于显式设置了TTL（如通过SET key value EX 300或EXPIRE）的key，对无过期时间的数据完全视而不见；单纯依赖短TTL会因Redis惰性+抽样删除机制导致过期键堆积和内存碎片，而volatile-lru则在内存不足时主动介入，从带TTL的冷门key中近似LRU地清理，弥补定时删除缺口；但若配置错误（如未设maxmemory-policy）、漏加EX参数、误用allkeys策略或混搭volatile-ttl，反而引发误删、雪崩或失效——真正稳住内存的关键，是业务写入时强制带上过期时间、明确标记“可淘汰”边界，并通过evicted_keys指标和压测验证策略是否真实生效。

volatile-lru 是什么，它到底清谁的数据

volatile-lru 不是“按访问频率淘汰所有 key”，而是只对设置了 TTL 的 key 生效。没设过 EXPIRE、SETEX 或 SET ... EX 的 key，哪怕长期不访问，它也完全无视。

这意味着：你必须主动给低价值数据打上“可淘汰”标记——靠 SET 命令的 EX 参数或后续 EXPIRE 命令，否则 volatile-lru 就等于没开。

• 常见错误：把日志类缓存、临时计算结果直接 SET key value，忘了加 EX 300，结果内存爆了也不淘汰
• 正确姿势：一律用 SET key value EX 300；批量写入时用 PIPELINE 包裹 SETEX，别漏掉时间参数
• 注意兼容性：volatile-lru 在 Redis 4.0+ 行为稳定，但 3.2 及更早版本在 maxmemory 触发时可能延迟响应，建议升级

为什么不能只靠短 TTL，还得配 volatile-lru

单纯设短 TTL（比如全部 EX 60）看似能自动清理，但实际会留下两个硬伤：内存碎片 + 过期键堆积。

Redis 不是到秒级就立刻删 key，而是采用惰性删除 + 定期抽样删除。高写入场景下，大量 key 同时过期，但没被及时扫描到，就会卡在内存里占着位置，直到下次访问才触发惰性删除——这时已造成内存水位虚高甚至 OOM。

• volatile-lru 在内存不足时主动介入，从已过期或未过期但冷门的带 TTL key 中选最久未用的删，补上定时删除的缺口
• 关键参数要调：maxmemory-policy volatile-lru 必须显式配置，Redis 默认是 noeviction，不设就拒绝写入
• 别迷信“越短越好”：EX 10 可能导致 key 频繁创建又销毁，CPU 消耗反升；实测 EX 120–300 + volatile-lru 组合在多数业务中更稳

如何验证 volatile-lru 真正在起作用

光看配置文件没用，得确认 Redis 实际淘汰行为和 key 分布是否符合预期。最容易踩的坑是：以为开了策略就万事大吉，结果 INFO memory 显示 evicted_keys 一直为 0。

• 先查是否真生效：redis-cli config get maxmemory-policy 输出必须是 volatile-lru，不是 volatile-lfu 或拼错成 volatitle-lru
• 观察淘汰指标：redis-cli info memory | grep evicted_keys，持续增长说明策略在干活；如果长期为 0，大概率是没设 TTL，或 maxmemory 根本没触达
• 模拟压测验证：用 redis-benchmark -n 10000 -t set --csv | grep "SET" 批量写带 EX 的 key，再手动 CONFIG SET maxmemory 1mb（远低于当前使用量），立刻查 evicted_keys 是否跳变

volatile-lru 和其他策略混用的风险点

有人想“保险起见”，把 maxmemory-policy 设成 allkeys-lru，觉得“反正都淘汰”。但这就彻底绕过了“低价值废数据”的前提——你那些带 TTL 的临时数据，和核心用户 session、热点商品信息混在一起竞争，反而可能把不该删的干掉。

• 绝对不要和 allkeys-* 策略共存：它们无视 TTL，会误杀你精心设计的长期 key
• volatile-ttl 看似合理（优先删快过期的），但容易导致“雪崩式过期”——一批 key 同时 TTL 归零，集中触发删除压力，不如 volatile-lru 分散负载
• 真正需要混合逻辑的场景，应该靠业务层控制：比如用不同前缀（tmp:xxx vs user:xxx）+ 单独实例隔离，而不是指望一个淘汰策略兜底

最常被忽略的一点：volatile-lru 的“LRU”不是严格 LRU，而是近似 LRU（采样 5 个 key 比较空闲时间），所以冷热区分没那么锐利。如果你的废数据访问模式极其随机，可能需要多留 20% 内存余量。

今天关于《Redis自动清理废数据方法解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！