volatile-random是“盲删”且语义误导性强，因其仅在带TTL的键中随机淘汰，但若业务统一设TTL（如全EX 3600），则实际等效allkeys-random，误让人以为只动临时数据；它完全忽略永久键（如config:timeout），导致内存压力集中于volatile键，淘汰更频繁、不可控。
volatile-random 为什么等于“盲删”，且语义误导性强
它只在带 EXPIRE 或 PEXPIRE 的 key 中随机挑选，但业务中若习惯给所有缓存统一设 TTL（比如全配 EX 3600），那 volatile-random 实际作用域就和 allkeys-random 完全一样——删的全是你的有效缓存，只是名字听起来“安全”而已。
更麻烦的是，它完全不碰永久键（如 config:timeout 这类 SET）。一旦这些键长期驻留、体积不小，内存压力会全部压到 volatile 键上，导致淘汰更集中、更频繁，反而放大抖动风险。
- 监控里
evicted_keys暴涨，但expired_keys很低 → 说明不是自然过期顶掉的，而是策略在硬扛 - 业务出现偶发 CacheMiss，查日志发现被删的 key 刚好是下游强依赖的临时凭证，但 TTL 还剩 28 分钟
- 你无法预测下一次删哪个，也无法通过
MEMORY USAGE或SCAN提前干预
它和 volatile-ttl / volatile-lfu 的关键行为差异在哪
volatile-random 不看访问时间、不看剩余 TTL、不看访问频次，只掷骰子。而 volatile-ttl 至少会优先删 TTL 剩得最少的——比如验证码（TTL=120s）比商品页缓存（TTL=3600s）更容易被清理，符合业务冷热分层逻辑；volatile-lfu 则能识别出“写入后从未被读过的埋点 key”，比随机靠谱得多。
-
volatile-ttl在 TTL 差异大的场景下淘汰可预期，适合多级缓存生命周期管理 -
volatile-lfu要求 Redis ≥ 4.0，且需确认lfu-log-factor和lfu-decay-time配置合理，否则计数器衰减过快，冷数据误判成热数据 -
volatile-random不需要调参，但代价是放弃所有可控性——这不是简化，是退化
什么情况下它才可能“勉强可用”
不是推荐用，而是没得选时的兜底手段。必须同时满足：
- 所有写入 Redis 的 key 都明确带 TTL，且 TTL 值跨度极大（从
10s到24h） - 业务能容忍任意一个临时 key 被删——例如：短时任务 ID 队列、一次性埋点缓冲区，删了就重发，无状态
-
lazyfree-lazy-eviction已设为yes，避免淘汰时同步释放大 value 导致主线程卡顿 - 监控显示
expired_keys远高于evicted_keys，证明大部分清理靠自然过期，volatile-random实际触发极少
只要其中一条不满足，它就不再是“兜底”，而是隐患源。
容易被忽略的配置联动陷阱
volatile-random 看似独立，实则和 maxmemory、active-defrag-threshold-lower、甚至客户端连接数都有关联。比如：
- 当
maxmemory设得太小（如512mb），而 key 数量又多，采样池不够大，随机淘汰实际变成“伪随机”，倾向删刚写入的小 key，漏掉真正该清的大 hash - 如果开启内存碎片整理（
activedefrag yes），而volatile-random正在高频淘汰，两者争抢 CPU，可能触发defrag-cpu-pct限流，进一步拖慢响应 - 主从架构下，从节点不会主动淘汰，但
volatile-random在主节点触发后，从节点仅靠复制流同步删除，若网络延迟高，会出现短暂的“从节点内存虚高”现象
真正难处理的从来不是策略本身，而是它如何在复杂配置与流量分布中悄悄放大不确定性。
