Redis怎样利用淘汰策略完成数据的自动清洗_设置短TTL并辅以volatile-lru实现低价值废数据的滚动-Redis-PHP中文网

volatile-lru 是仅对设置了 ttl 的 key 生效的近似 lru 淘汰策略，不淘汰无过期时间的 key；必须显式配置 maxmemory-policy 且配合 expire 或 set ex 使用，否则无效。

redis怎样利用淘汰策略完成数据的自动清洗_设置短ttl并辅以volatile-lru实现低价值废数据的滚动

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

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

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

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

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

下载

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

有人想“保险起见”，把 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% 内存余量。