Redis清理无热度图片缓存技巧

Redis的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 本质是兜底策略，不是冷数据治理方案。真正要清理低热度图片，得把“热度”显式记录下来：

实操建议：

• 用 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，允许短暂超限，可缓解突发写入导致的频繁淘汰抖动

冷图清理不是靠“随机”就能蒙混过关的事。真正稳定运行的图片缓存服务，基本都放弃了纯内存淘汰，转而用带时间戳的辅助结构 + 定时批处理来控制生命周期。随机策略只适合 key 访问模式完全不可预测、且能容忍误删的场景——图片缓存显然不属于这一类。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。