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 的捷径。