Redis缓存污染指低频、冷门、临时或失效Key长期滞留内存挤占热点数据空间；其主因是LRU近似实现（随机采样淘汰）、未设过期时间及临时key混入LFU统计，需配合expire策略、命名规范与监控验证。
Redis缓存污染不是“数据脏了”，而是指大量低频、冷门、临时或已失效的Key长期滞留内存，挤占了真正热点数据的空间——allkeys-lru 或 allkeys-lfu 本身不能自动解决污染，必须配合正确的配置、监控和业务配合才能起效。
为什么开了allkeys-lru还是有污染？
Redis 的 LRU 是近似实现：它不维护全局访问时间链表，而是在每次需要淘汰时，随机采样 maxmemory-samples（默认 5）个 key，从中挑出最久未访问的淘汰。这意味着：
- 如果冷数据恰好没被抽中，就可能长期存活；
- 批量写入大量一次性 key（如导出任务 ID、临时 token），它们在首次写入后就再无访问，但因未被采样，不会被及时清理；
-
allkeys-lru对无过期时间的 key 也生效，但若业务习惯用set key val而不设expire，这些 key 会永远参与 LRU 竞争，加剧误淘汰热点数据的风险。
volatile-lfu 比 allkeys-lfu 更适合防污染？
不一定。LFU 在 Redis 中通过每个 key 的 24 位访问计数器 + “衰减逻辑”实现，但它的适用前提是：你希望保留高频访问的长期有效数据（如用户配置、商品基础信息）。而污染往往来自短期、单次、带业务上下文的 key（如 order:tmp:123456）。这类 key 天然不该进 LFU 统计——它们访问频次永远是 1，却和其他真实高频 key 一起参与淘汰竞争，反而稀释了 LFU 的有效性。
更合理的做法是：
- 对明确生命周期的 key，强制使用
setex或expire，让其进入volatile-*策略池； - 把污染源 key 命名带上可识别前缀（如
tmp:、batch:），便于后续用scan批量清理； - 避免在 LFU 模式下混用长期 key 和临时 key——否则
allkeys-lfu会把刚被访问一次的临时 key 当作“低频”保留，而挤掉真正高频但近期稍沉寂的 key。
如何验证当前策略是否真正在对抗污染？
不能只看 INFO memory 里的 maxmemory_policy，要结合实际淘汰行为观测：
- 执行
INFO stats，检查evicted_keys是否持续增长，且expired_keys占比极低 → 说明过期机制没兜底，淘汰全靠 LRU/LFU，污染风险高； - 用
redis-cli --bigkeys或scan 0 match tmp:* count 1000快速确认是否存在大量命名规律的临时 key； - 开启慢日志 +
CONFIG SET notify-keyspace-events Ex，监听__keyevent@0__:expired事件，确认过期 key 是否被惰性/定期删除真正回收（而非堆积）。
真正的污染治理不在“换策略”，而在让 key 自带生命周期语义——LRU/LFU 是兜底手段，不是替代 expire 的捷径。
