Redis如何清理没有访问热度差异的缓存图片_采用allkeys-random进行无差别随机释放内存
allkeys-random 真的“无差别”吗？先看它到底删什么
很多开发者一看到“random”，就以为allkeys-random策略会无差别地随机清理所有缓存。其实，这里有个关键前提容易被忽略：它只在Redis内存触及maxmemory上限，并且有新的写入操作试图申请更多空间时，才会被触发执行。换句话说，它既不会主动去扫描所谓的“冷数据”，也不会根据key的最近访问时间、value大小或数据类型来做判断——只要这个key还存在于主字典（db->dict）里，它就有“中签”被删除的可能。
但必须划清一个界限：它不负责删除已过期的key。如果你的图片key设置了EXPIRE，它们会优先由Redis自身的惰性删除和定期删除机制来处理。allkeys-random的随机范围，仅限于那些没有设置过期时间的永久key。所以，如果图片缓存全部设为永不过期，哪怕它们早已无人问津，也会一直占据着内存，直到内存用满、淘汰机制被迫启动的那一刻。
这里有个常见的监控盲点：当INFO memory命令显示mem_not_counted_for_evict这个指标不为零时，就意味着有大量带过期时间的key正排队等待清理。此时，allkeys-random实际可操作的key池，远比想象中要小。
为什么图片缓存用 allkeys-random 容易误伤热图
图片缓存场景通常存在明显的热度分层：首页轮播图访问频率最高，用户头像属于中等热度，而一些历史活动的宣传海报，可能自存入后就再也没被打开过。allkeys-random的问题在于，它对这三者一视同仁——一张刚刚被高频访问的头像，和一张沉寂了三年的海报，在下一次淘汰触发时，被删除的概率是完全相同的。
这种“无差别”会带来几个具体的影响：
- 首先，Redis的“随机”并非数学上的绝对均匀。它基于字典桶遍历和伪随机采样，在key分布密集的区段，被选中的概率会略微偏高。
- 其次，它不考虑value的大小。删除一张占用5MB的大图，和删除一百张50KB的缩略图，所能释放的内存天差地别，但策略本身无法做出这种高效选择。
- 最危险的是，如果客户端没有设计健全的重载逻辑（例如，缓存被删后能自动回源重建），那么热门图片的突然消失，很可能瞬间引发对源站的雪崩式请求，导致服务不稳定。
想“无差别清理冷图”，该换什么策略
说到底，allkeys-random更像是一种简单粗暴的兜底机制，而非精细化的冷数据治理方案。真想清理低热度图片，核心思路是把“热度”这个信息显式地记录和管理起来。
市场上比较成熟的实操方案通常是这样：
- 使用一个
ZSET有序集合来维护图片key的热度。每次执行ZADD img_heat [当前时间戳] [图片key]，并在每次GET操作后，用ZADD ... XX CH命令更新该key的最后访问时间戳。 - 部署一个定时任务，例如每小时运行一次，通过
ZRANGEBYSCORE img_heat -inf (当前时间戳-86400)命令，筛选出过去24小时内未被访问的key，然后进行批量UNLINK异步删除。 - 如果确实需要依赖内存淘汰策略，那么
allkeys-lru通常是比随机更好的选择。它至少能保证最近被使用过的数据得以保留，命中率比纯随机要高得多。 - 一个基础但有效的习惯：避免给所有缓存图片设置永不过期。即使设一个较长的过期时间（例如
EXPIRE key 604800，即7天），也能让Redis的过期删除机制分担大部分清理压力。
配置 allkeys-random 时最容易漏掉的三个参数
仅仅把maxmemory-policy改成allkeys-random是远远不够的。下面这三个参数如果配置不当，淘汰策略可能根本不会按预期工作：
第一，maxmemory必须设置为一个具体的数值（比如2gb），不能是0或者被注释掉。Redis默认是不限制内存使用的，这意味着淘汰机制永远不会被激活。
第二，maxmemory-samples这个参数值得关注。它默认值为5，代表每次淘汰时随机采样5个key，然后从中删除一个。在存储大图片value的场景下，适当调高这个值（例如10~20）可以略微提升找到“合适”删除目标的机会，但要注意权衡，设置过高会增加CPU的采样开销。
第三，对于Redis 7.2及以上版本，maxmemory-eviction-tenacity这个参数开始发挥作用。它默认是0，表示严格守候maxmemory红线。如果将其设为1，则允许内存使用量短暂超标，这有助于缓解突发写入流量导致的频繁淘汰抖动，让服务更平滑。
总而言之，冷图清理不是一场靠“随机”就能蒙混过关的游戏。观察那些真正稳定运行的图片缓存服务，它们大多已经放弃了将清理工作完全寄托于内存淘汰策略，转而采用“辅助数据结构记录热度+定时任务批处理”的组合拳，来精准控制缓存的生命周期。纯随机策略，只适用于那些访问模式完全不可预测、且业务能够容忍任何key被随时删除的场景——而图片缓存，显然不属于这一类。
