volatile-random仅适用于临时数据无访问优先级且删除无业务影响的场景，如验证码、分布式锁占位key、秒杀预热计数器、灰度流量标记等，因其零开销o(1)随机淘汰，但要求maxmemory显式配置且存在足够volatile键。
volatile-random 适合哪些真实业务场景
它只在设置了 TTL 的键里随机删，不看访问频次、不看剩余时间、也不碰没设过期的键。这种“无脑随机”反而是某些场景下的最优解。
适用的核心前提是：你有一批明确的临时数据，且这些数据之间没有访问优先级差异，删除谁对业务影响都一样。
- 验证码、短信口令类数据：每个 key 生命周期短（如 5 分钟），写入即带
EXPIRE，且单个 key 被查一次就作废；删错一个不影响整体可用性 - 分布式锁的临时占位 key：用
SET key val NX EX 30写入，锁本身无状态依赖，随机淘汰一个锁 key 不会导致死锁或数据不一致 - 秒杀活动中的预热计数器：大量
INCR+EXPIRE生成的临时计数 key，业务逻辑只关心“当前是否超限”，不关心哪个计数器被删 - 灰度流量标记 key：例如
gray:user:123设了 2 小时 TTL，用于动态路由；即使被随机删掉，下次请求会重建，无副作用
为什么不用 volatile-lru 或 volatile-ttl 替代
volatile-lru 需要维护访问时间戳，volatile-ttl 要计算剩余生存时间——两者都会带来额外 CPU 开销和内存跟踪成本。而 volatile-random 几乎零开销：Redis 只需从过期键集合中抽一个下标，O(1) 完成。
如果你的临时数据量极大（比如每秒写入 10 万+ 带 TTL 的 key），又不需要保热点、也不需要按到期顺序清理，那 volatile-random 是唯一能扛住高吞吐淘汰压力的策略。
注意：它不适用于以下情况：
– 有明显访问倾斜（比如 5% 的 key 承担 95% 查询）
– 过期时间跨度极大（从 1 秒到 24 小时混存），此时 volatile-ttl 更合理
– 依赖 key 存活时长做业务判断（如“用户最后活跃时间”存为 TTL key）
配置时容易忽略的两个硬约束
这个策略生效的前提是：必须同时满足两个条件，缺一不可。
-
maxmemory必须显式设置，否则 Redis 默认不限制内存，淘汰机制根本不会触发 - 必须有足够数量的带
TTL的 key；如果所有 key 都没设过期时间，volatile-random会退化成拒绝写入（等效于noeviction）
验证方式很简单：redis-cli --raw info memory | grep -E "(used_memory|maxmemory)" 看是否已生效，再用 INFO stats | grep evicted_keys 观察淘汰计数是否增长。
真正难的是判断“你的临时数据是否真的彼此等价”——业务上看似一样的 key，可能隐含时序、权重或依赖关系。这时候随机删，删掉的不是内存，是逻辑一致性。
