volatile-random 真的能“及时”淘汰临时缓存吗？

不能。它不看时间戳、不按到期顺序，纯随机选 key 淘汰——所谓“及时”，只取决于你写入量、过期 key 占比和内存压力频率。如果大量 key 同时设了 EXPIRE 但还没被 Redis 主动扫描到，它们就卡在内存里，volatile-random 完全不管它们“该不该走了”。

常见错误现象：INFO memory 显示 mem_usage 持续上涨，expired_keys 增速远低于预期，而 evicted_keys 几乎为 0；或者压测时缓存命中率骤降，但日志里没看到大量 key 过期记录。

• 使用场景仅适合：临时任务生成的缓存本身生命周期短（秒级），且你主动控制写入节奏（比如每秒最多写 100 个新 key），同时允许少量“漏网之鱼”多留几秒
• 它不依赖 Redis 的惰性删除或定期删除机制，只在内存不足触发淘汰时才工作——也就是说，没到 maxmemory 上限前，一个快过期的 key 和一个刚写入的 key 对它来说毫无区别
• 如果你用的是 Redis 6.0+，注意 volatile-random 在 maxmemory-policy 中仍有效，但默认策略已改为 noeviction，不显式配置就根本不会淘汰

为什么不用 volatile-ttl 而选 volatile-random？

因为 volatile-ttl 看似合理，实则在高并发定时任务场景下容易拖慢主线程。每次淘汰都要遍历带过期时间的 key 并排序，CPU 开销随待淘汰 key 数量非线性增长；而 volatile-random 只需从过期 key 集合里抽一个，O(1) 完事。

性能影响很实际：当你的定时任务每秒生成 5k 个带 EXPIRE 的 key，且平均 TTL 是 30 秒，那内存中随时有约 15w 个 volatile key——此时 volatile-ttl 的淘汰延迟可能达毫秒级，而 volatile-random 基本稳定在微秒级。

• volatile-ttl 在 Redis 7.0 后已标记为“legacy”，官方文档明确建议避免用于高吞吐场景
• 如果你的任务缓存本身没有严格优先级（比如都是同构的计算结果，谁先过期谁后过期无所谓），那就别为“更准”牺牲“更快”
• 注意：Redis 不会为 volatile-random 维护单独的过期 key 索引，它依赖的是每个 db 的 expires 字典，所以 key 越多，随机采样时空转概率略升（但影响极小）

如何让 volatile-random 实际生效？三个硬性前提

缺一不可，少一个都会导致“设了策略却没淘汰”。

• 必须配置 maxmemory，例如 maxmemory 2gb；没设上限，Redis 根本不触发任何淘汰逻辑
• 必须把策略设成 volatile-random，命令是 CONFIG SET maxmemory-policy volatile-random；注意不是 allkeys-random，后者会删掉你不想动的持久化数据
• 所有临时缓存 key 必须显式设置过期时间，用 SET key value EX 60 或先 SET 再 EXPIRE；没加 EXPIRE 的 key 不进 expires 字典，volatile-random 瞥都瞥不见它

典型翻车点：用 SETNX 写 key，然后另起一个定时器调用 EXPIRE —— 若中间 Redis 重启或主从切换，EXPIRE 就丢了，这个 key 变成永久驻留的“幽灵”。

临时缓存写入时最容易忽略的兼容性细节

Redis 5.0 之前，EXPIRE 对不存在的 key 返回 0，但不会报错；5.0+ 默认返回 0，可配合 SET ... XX 或 SET ... NX 控制写入条件——但很多人忘了，volatile-random 只认“有没有过期时间”，不认“key 是怎么来的”。

• 用 SET key value EX 30 NX 是安全的：一步到位，原子写+过期，不怕竞态
• 避免分两步：SET key value + EXPIRE key 30；网络分区或 client crash 会导致 key 永久残留
• 如果你用 Lua 脚本批量写临时缓存，确保脚本里每个 SET 都带 EX 参数；Redis 不会自动给脚本内写的 key 补过期时间
• 集群模式下，key 必须落在同一 slot 才能被单个 EVAL 脚本统一处理；否则得用 ASK 或 MOVED 重定向，增加超时风险

真正难的不是选策略，而是让每个临时 key 从诞生那一刻起，就带着确定的、不可丢的过期契约进内存——别的都能补，这一步漏了，后面全白搭。