allkeys-random策略从所有键中随机淘汰，不考虑访问时间、频次或TTL，因此可能误删热key；而volatile-random仅在设置了过期时间的键中随机淘汰，具有安全边界。
它不保证缓存命中率，也不保护热数据，所以生产环境基本不用 allkeys-random —— 不是它不能用，而是用了容易出意料之外的问题。
allkeys-random 为什么会随机删掉热 key
这个策略完全不看访问时间、不看访问频次、不看 TTL，只靠伪随机数选一个键删。哪怕你刚 GET 过 user:10086:profile 十次，只要内存满了，它照样可能把它干掉。
- Redis 不维护任何访问元信息，
allkeys-random就是真·掷骰子 - 没有“冷热”概念，也就没有“保热放冷”的逻辑基础
- 在流量倾斜明显的服务里（比如某几个用户被高频访问），随机淘汰大概率误伤高价值数据
和 volatile-random 的关键区别在哪
很多人混淆 allkeys-random 和 volatile-random，但它们的筛选范围完全不同：
-
allkeys-random：从 所有键 中随机挑，不管有没有EXPIRE -
volatile-random：只在 设置了过期时间的键 里随机挑，天然排除了长期存活的配置类、用户会话类等核心数据
换句话说，volatile-random 至少有个安全边界；而 allkeys-random 是把命门直接交给了 RNG（随机数生成器）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
什么场景下才可能考虑 allkeys-random
只有当你的数据完全无状态、无访问偏好、且丢失任意一个 key 都不影响业务时，它才有点存在意义：
- 纯临时 token 池，比如
tmp:uuid4()类型的短时凭证，生命周期 - 压力测试中模拟极端内存压力，验证下游降级逻辑是否健壮
- 单机开发/本地调试环境，
maxmemory设得极小（如 2MB），只为快速触发淘汰看日志
注意：这些都不是“生产需求”，而是“非生产妥协”。一旦写进 redis.conf 上线，就等于放弃对缓存行为的基本控制权。
比随机更糟的是——它掩盖了容量规划问题
allkeys-random 最隐蔽的风险，是让团队误以为“内存够用”，因为删得快、不报错。但它不解决根本问题：
- 不会提醒你 key 膨胀（比如没清理的旧日志 hash）
- 不会暴露大 value 占用（比如一个
SET存了 500KB 的序列化对象） - 不会触发告警，直到某次随机删掉了唯一一份订单缓存，下游开始报
CacheMissException
真正该做的，是用 INFO memory 定期采样、用 MEMORY USAGE 抽查大 key、用 SCAN + TTL 统计过期分布——而不是依赖一个连自己都解释不了删除逻辑的策略。
