allkeys-random 并非真正无差别：它只在内存达限且写入触发时，从永不过期的主字典key中伪随机删除，不考虑访问频次、大小或热度，易误删热图；应改用allkeys-lru或zset+定时清理。
allkeys-random 真的“无差别”吗？先看它到底删什么
allkeys-random 策略只在 Redis 内存达到 maxmemory 限制、且写入新数据触发淘汰时才生效。它不会主动扫描或清理“冷图”，也不会区分 key 的访问时间、大小或类型——只要 key 在主字典（即 db->dict）里，就可能被随机选中删除。
但要注意：它**不删过期 key**。如果图片 key 设置了 EXPIRE，它们会先由 Redis 的惰性+定期删除机制处理；allkeys-random 只在剩余的**永不过期 key 中随机挑**。所以如果你的图片缓存没设过期时间，又长期没人访问，它们就会一直卡在内存里，直到触发淘汰。
常见误判现象：INFO memory 显示 mem_not_counted_for_evict 非零，说明有大量带过期时间的 key 正在等待被清理，此时 allkeys-random 实际可选范围比你以为的小得多。
为什么图片缓存用 allkeys-random 容易误伤热图
图片缓存通常有明显热度分层：首页轮播图 QPS 高，用户头像访问频次中等，历史活动海报几乎无人点开。但 allkeys-random 对这三类一视同仁——哪怕某张头像刚被读取过 10 次，下一次淘汰仍和一张三年没访问的海报有相同概率被删。
关键影响点：
- Redis 的“随机”基于字典桶（bucket）遍历 + 伪随机采样，并非真均匀分布；key 密集区段被抽中概率略高
- 大图 value 占用内存多，但
allkeys-random不按 size 权重选，删一张 5MB 图和删一百张 5KB 缩略图释放的内存量差异极大 - 客户端若没做重载逻辑（比如删完立刻回源生成），可能引发雪崩式源站请求
想“无差别清理冷图”，该换什么策略
allkeys-random 本质是兜底策略，不是冷数据治理方案。真正要清理低热度图片，得把“热度”显式记录下来：
实操建议：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
ZSET存储图片 key + 最后访问时间戳（ZADD img_heat 1698765432 /img/abc.jpg），每次GET后ZADD ... XX CH更新 - 定时任务（如每小时）用
ZRANGEBYSCORE img_heat -inf (now-86400找出 24 小时未访问的 key，再批量UNLINK - 如果必须用内存淘汰，改用
allkeys-lru——它至少能保留最近被访问过的图，比纯随机靠谱得多 - 避免给所有图片设永不过期；统一加
EXPIRE key 604800（7 天），让过期机制承担主要清理压力
配置 allkeys-random 时最容易漏掉的三个参数
光改 maxmemory-policy allkeys-random 不够，以下三项不配齐，策略可能压根不触发：
maxmemory 必须设为具体值（如 2gb），不能是 0 或注释掉；Redis 默认不限制内存，淘汰机制永不启动
maxmemory-samples 默认是 5，即每次随机采样 5 个 key 再删一个。对图片这类大 value 场景，建议调到 10~20，略微提升淘汰效率（但别设太高，会增加 CPU 开销）
maxmemory-eviction-tenacity（Redis 7.2+）默认 0，表示严格遵守 maxmemory 上限；若设为 1，允许短暂超限，可缓解突发写入导致的频繁淘汰抖动
