allkeys-lru更常被选用，因其不依赖ttl，直接按访问热度淘汰所有key，契合热点数据无ttl但需常驻的业务实际；volatile-lru仅淘汰带ttl的key，易因漏设ttl导致核心缓存失保护或临时数据过早淘汰。
allkeys-lru 为什么比 volatile-lru 更常被选中
因为绝大多数真实缓存场景里，你无法、也不该靠「是否设了过期时间」来区分数据重要性；allkeys-lru 直接按访问热度做取舍，更贴近业务实际——热门视频、高频接口响应、用户最近搜索词，这些关键缓存往往根本不需要 TTL，但必须留得住。
volatile-lru 的隐性陷阱：过期键范围太窄
一旦某些核心缓存（比如 video:10086:meta）没加 EXPIRE，它就完全不在 volatile-lru 的淘汰候选池里——看起来是“受保护”，实则是把淘汰压力全转嫁给那些带 TTL 的临时数据（如 user:session:xxx），导致 session 提前失效、登录态异常等连锁问题。
-
volatile-lru只看ttl > 0的键，哪怕你只漏设一个热点 key 的过期时间，整个淘汰逻辑就失焦 - 运维上很难保证所有缓存写入都严格配 TTL，尤其在多语言、多 SDK 混合调用时
- Redis 不会警告“你有 2000 个 key 没设 TTL，它们将永不参与淘汰”，错误是静默发生的
allkeys-lru 的实际优势：不依赖 TTL 语义，只认访问模式
它对所有 key 一视同仁，靠近似 LRU 抽样（默认 maxmemory-samples 5）判断谁最久没被碰过。这意味着：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 刚上线的热门商品页缓存，即使没设 TTL，只要被大量请求，就会自然留在内存里
- 冷门的老用户配置项，哪怕设置了 7 天 TTL，也会因长期无访问而优先被淘汰
- 避免人为给 key 打“临时/永久”标签带来的设计负担和误判风险
- 配合
maxmemory-samples 10调高抽样数，能进一步提升淘汰准确性，代价只是轻微 CPU 上升
什么时候还该用 volatile-lru
极少数明确需要「强制隔离」的场景才考虑它：
- Redis 同时混存缓存 + 少量持久化状态（如分布式锁的
lock:order:123，必须永驻） - 遗留系统无法改造，只能靠 TTL 标记临时数据，且你能 100% 控制所有写入路径
- 业务要求“过期键必须优先清掉”，比如秒杀库存倒计时类数据，TTL 本身就是淘汰信号
但注意：volatile-lru 不等于“安全”，它只是把淘汰范围收窄了——如果所有 key 都设了 TTL（比如统一设 24h），那它和 allkeys-lru 行为几乎一致，反而失去策略本意。
