volatile-lru仅淘汰设置了过期时间的键中最近最少使用的，allkeys-lru则对所有键一视同仁按LRU淘汰；核心区别在于作用范围与数据安全性。
Redis需要多种内存淘汰策略，不是为了“功能丰富”，而是因为不同业务对数据生命周期、访问模式和容错能力的要求根本不同。选错策略轻则缓存命中率暴跌，重则把关键数据误删。
volatile-lru 和 allkeys-lru 的区别在哪？
区别核心在于「作用范围」和「数据安全性」。
-
volatile-lru只在设置了EXPIRE或PEXPIRE的键中做 LRU 淘汰，没设过期时间的键永远不会被它动——适合混存「缓存+持久配置」的场景，比如 session 缓存（有 TTL）和系统参数（永久有效）共存 -
allkeys-lru对所有键一视同仁，不管有没有EXPIRE，只要内存满就可能被淘汰——适合纯缓存场景，比如 CDN 后端或 API 响应缓存，所有数据都可重建 - 误用风险：把
allkeys-lru用在含重要配置项的实例上，CONFIG SET写入的键可能被随机踢掉；反过来，volatile-lru在全量数据都没设 TTL 时会退化为noeviction，写请求直接报OOM command not allowed when used memory > 'maxmemory'
LFU 策略真的比 LRU 更“聪明”吗？
LFU 不是万能升级版，它只在「访问频次差异极大」的场景下才有优势，且代价明确。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
allkeys-lfu依赖每个键的访问计数器，Redis 用 16 位字段存储频率值，并通过衰减机制（lfu-decay-time配置）降低旧访问的影响——这意味着它更倾向保留长期高频访问的键，而非刚火起来的热点 - 典型适用场景：商品详情页缓存（头部 SKU 被反复刷）、用户画像特征（稳定读取）、API token 白名单（长期有效且高频校验）
- 不适用场景：突发流量型热点（如秒杀商品），LFU 计数来不及上升就被淘汰；或者写多读少的场景（计数器徒增开销，无实际收益）
- 性能提示：
maxmemory-samples默认为 5，但 LFU 对采样敏感度高于 LRU，调高到 10～20 可提升准确性，但也增加 CPU 开销
volatile-ttl 为什么常被低估？
它不是“低端策略”，而是专为「天然有时效性」的数据设计的零成本淘汰方案。
-
volatile-ttl不统计访问时间或频次，只看剩余TTL，优先淘汰TTL最小的键——逻辑极简，CPU 开销几乎为零 - 最适合场景：验证码（
SET key code EX 300）、临时令牌（JWT refresh token）、短期会话（SETEX session:123 600 data），这些数据本就该“自然死亡”，无需算法干预 - 陷阱：如果大量键设置了相同或相近的
TTL（比如统一设 3600 秒），volatile-ttl会退化为随机淘汰，此时不如换volatile-lru或volatile-lfu - 注意：
TTL是动态值，EXPIREAT设置的绝对时间点也会影响排序，不是设置完就固定不变
noeviction 真的只是“保命策略”吗？
它是最保守的选择，但保守不等于懒政——它强制你直面容量规划问题。
-
noeviction下，内存满后所有写命令（SET、HSET、LPUSH等）返回错误，但读和删仍可进行——这迫使客户端必须处理OOM错误，比如降级、熔断或触发扩容流程 - 金融类系统、审计日志、配置中心等场景会主动启用它，因为宁可拒绝写入，也不能让 Redis 自行决定删哪条记录
- 容易忽略的细节：主从复制时，
noeviction在从节点也生效，但主节点写失败不会同步给从节点，可能导致主从状态不一致；需配合监控告警（mem_usage、evicted_keys指标）提前干预
真正难的不是记住八种策略的名字，而是理解你的数据有没有 TTL、访问是否集中、丢失某条键的后果有多重——这些判断没法靠文档抄答案，得看业务日志里的 KEYS * 分布、INFO memory 中的 used_memory_peak 波动，以及 SLOWLOG 里淘汰动作是否卡住了主线程。
