volatile-lfu只淘汰带过期时间的key中访问频次最低者，适用于混存场景中需保护永久配置、仅清理临时缓存的情形，但要求所有缓存必须显式设置expire。
volatile-lfu 适合混存场景但要求所有缓存都设 expire
如果你的 Redis 同时存了两类数据：一类是永久有效的配置项（比如 app_config），另一类是带过期时间的业务缓存（比如 user:123:profile），那就不能选 volatile-lfu 或 volatile-lru——因为没设 expire 的 key 完全不会参与淘汰，内存满时只会报 OOM command not allowed when used memory > maxmemory 错误。
实际踩坑点：
- 开发写缓存时漏加
EXPIRE或SETEX，导致该 key 永久驻留，挤占空间 - 运维只看
used_memory增长快，却没查db0:keys=1000,expires=200这类指标，误判为“缓存命中率低”，其实只是 800 个永久 key 占着不动 -
volatile-ttl看似安全，但若大量 key 设置相同 TTL（比如统一 30 分钟），会集中在某一秒批量失效，触发密集淘汰，CPU 突增
allkeys-lfu 对纯缓存最稳但会误删配置型数据
当 Redis 只用作缓存，不存任何长期有效数据（比如没有 feature_flags、dict:status 这类字典），allkeys-lfu 是当前最推荐的策略。它全局统计访问频次，能自然沉淀热点，长期运行缓存命中率比 LRU 高 12%–18%（2025 年行业实测数据）。
但要注意：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 一旦混入配置类 key，哪怕只设了一次
SET feature:on，它也会被当作普通缓存参与 LFU 计数，可能在低频访问后被误删 -
maxmemory-samples默认是 5，采样数太小会导致 LFU 计数偏差大；高并发下建议调到 10–15，但会略微增加 CPU 开销 - LFU 的访问计数有衰减机制（默认每分钟右移 1 位），对突发流量友好，但如果你的业务存在“每天固定时段高峰”，衰减周期需配合业务节奏调整
noeviction 在配置中心场景下反而最安全
有些系统把 Redis 当配置中心用，比如存 redis.conf 里加载的全部开关项：payment:enable、push:rate_limit。这类数据写一次、读多次、永不过期。这时必须用 noeviction。
原因很直接：
- 其他任何淘汰策略都可能把关键开关删掉，导致功能静默失效（比如
payment:enable被allkeys-lfu清掉，支付突然不可用） - 只要监控好
used_memory_rss和mem_fragmentation_ratio，提前扩容或清理旧配置，就不会触发 OOM - 写失败时客户端收到
(error) OOM command not allowed when used memory > maxmemory，比静默丢数据更容易定位问题
volatile-random 和 allkeys-random 线上基本不用
这两个策略在真实业务中几乎没有合理使用场景。它们不区分冷热，完全随机删 key，会导致缓存命中率断崖式下跌——你刚预热好的热点商品详情页，可能下一秒就被 volatile-random 删掉。
唯一可能用到的情况：
- 做压测时临时启用
allkeys-random，模拟极端内存压力下的服务降级行为 - 某些极简 IoT 设备本地 Redis，数据本身无价值，只求写不阻塞，且能接受随时丢失
- 千万别在配置了
maxmemory的生产实例里留着默认策略——Redis 3.0+ 默认是noeviction，但很多运维脚本会覆盖成volatile-lru，得确认清楚
