volatile-random适合临时数据多、访问模式不可预测且能容忍误删的场景，如短期token、秒杀排队号、幂等key、ack标记等；它只删带TTL的key，完全随机，无序、低开销、不维护元数据。
volatile-random 适合什么业务场景
它只删设置了 TTL 的 key，且完全随机，不看访问时间、不看访问频次、也不看剩余过期时间。这意味着它天然适合“临时数据多、访问模式不可预测、且能容忍误删”的场景。
典型例子包括：用户登录态的短期 token（比如 5 分钟有效期）、秒杀活动中的临时排队号、API 请求的防重幂等 key、消息队列的临时 ack 标记。这些数据本就该短命，丢了也不影响核心状态，重生成成本极低。
- 数据生命周期明确，都带
EXPIRE或SETEX - 写入高频、读取稀疏，无法用 LRU/LFU 做有效判断
- 业务对“删了哪个 key”无感知，也不依赖淘汰顺序做逻辑兜底
- 集群规模大、key 数量多，需要低开销的淘汰机制（
volatile-random比volatile-lru少维护访问时间戳，CPU 占用更低）
为什么不能用 volatile-random 保护核心缓存
它完全无视 key 的重要性或热度，只要带 TTL 就可能被抽中。如果你混存了两类数据——比如会话信息（session:123，EXPIRE 30m）和商品详情缓存（item:456，也设了 EXPIRE 1h），那么后者一样可能被随机删掉，导致缓存击穿风险上升。
更危险的是：一旦你误给本不该淘汰的 key 加了 TTL（比如配置漏写、代码里默认加了 24h 过期），它就会进入 volatile-random 的候选池，变成潜在牺牲品。
- 无 TTL 的 key 完全免疫，但一旦加了 TTL，就失去“豁免权”
- 它不区分
SET和SETEX，只要 Redis 内部标记为 volatile，就参与淘汰 - 监控时看不到淘汰倾向性，只能靠
INFO memory中的evicted_keys计数 + 日志采样反推
配置时最容易踩的坑
maxmemory 必须显式设置，否则 volatile-random 不生效——Redis 默认策略是 noeviction，内存超限直接拒绝写入，根本不会触发淘汰。
另外，Redis 6.0+ 开始支持内存用量动态计算（含 client output buffer、aof buffer 等），但 maxmemory 只限制 keyspace 数据占用。如果业务大量使用 pub/sub 或 big value，实际内存可能远超配置值，导致 OOM 被系统 kill，而不是走淘汰流程。
-
maxmemory-policy volatile-random必须和maxmemory同时存在，缺一不可 - 不要依赖
CONFIG SET临时修改策略，重启后丢失；生产环境务必写进redis.conf - 用
INFO stats查看evicted_keys增速，结合INFO memory的used_memory_human判断是否频繁触发
和 volatile-ttl、volatile-lfu 的关键区别在哪
三者都只处理带 TTL 的 key，但行为逻辑完全不同：volatile-ttl 优先删快过期的，适合清理“临期垃圾”；volatile-lfu 优先删冷数据，适合保留热点；而 volatile-random 是唯一一个不引入额外元数据开销、也不做任何排序/扫描的策略。
换句话说，它不是“智能选择”，而是“快速甩锅”。当你的服务对延迟敏感、又不想为淘汰逻辑增加 CPU 压力时，它反而成了最稳的选择——前提是业务能接受随机性。
-
volatile-ttl需要维护每个 key 的剩余 TTL 排序，内存碎片略高 -
volatile-lfu要记录访问频次（counter），有精度衰减和 counter 溢出问题 -
volatile-random只需在 volatile keys 集合里做一次随机采样，常数时间复杂度
volatile-random 就会忠实地执行它的随机使命——不管那个 key 对业务多关键。 
