Redis 6.0 LFU 仅比 LRU 更抗缓存污染，但需配合key生命周期分层、合理设置lfu-decay-time与lfu-log-factor，且禁用allkeys-lfu处理混合TTL场景，否则冷key滞留导致命中率暴跌。
Redis 6.0 的 LFU 策略本身不能“解决”缓存污染问题，它只是比 LRU 更抗污染；真正起效的前提是：你已对 key 做了生命周期分层，并配合调优了 lfu-decay-time 和 lfu-log-factor，否则开 allkeys-lfu 反而会让冷数据赖着不走。
为什么开了 allkeys-lfu 还是缓存命中率暴跌？
常见错误是把所有 key（含临时导出、批量同步生成的冷 key）都扔进同一个 LFU 池子。LFU 不区分语义，只看 counter；而这些 key 往往只被读一次（如 HGETALL user:profile:*），counter 被概率性抬到 1 后，若没设 TTL，就会永远卡在 1，和真实热 key（product:1001）同池竞争——结果就是热 key 被误淘汰。
必须做到：
- 长期有效 key（如用户基础信息）用
volatile-lfu+SETEX显式设 TTL - 临时 key（如
tmp:export:20261019、batch:sync:456）必须带明确过期时间，不能依赖策略兜底 - 禁用
allkeys-lfu处理混合生命周期场景，它适合全 key 都有 TTL 的架构
OBJECT FREQ 返回 0 或始终不上升？检查这三个点
OBJECT FREQ 返回的是 8 位对数频次（0–255），不是真实访问次数。返回 0 通常不是 bug，而是以下情况之一：
- 该 key 从未被访问过（LFU counter 只在访问时按概率更新，写入不触发）
- 当前策略不是
volatile-lfu或allkeys-lfu（CONFIG GET maxmemory-policy确认） - 刚切换策略，历史 counter 不会重算，需等后续访问逐步积累
注意：lfu-log-factor 默认为 10，意味着低频访问增长快、高频后增长极慢。比如访问 100 次可能 freq 才到 12，这不是异常，是设计使然。
怎么调 lfu-decay-time 和 lfu-log-factor？
这两个参数不调，LFU 就只是个“看起来高级”的摆设。它们直接影响 counter 是“记性好”还是“忘性大”：
-
lfu-decay-time（单位：分钟）：决定计数器多久衰减一次。默认 1 表示每分钟右移一位（≈除以 2）。若业务有小时级周期高峰（如每小时报表刷新），这个值太小会导致老热点被快速清零；建议设为 60 或更高 -
lfu-log-factor：控制 counter 增长斜率。默认 10 对中低频友好；若要让突发流量更快“冒头”（比如秒杀预热），可降到 1–3，但会牺牲对长稳热 key 的区分度 - 修改后执行
CONFIG REWRITE持久化，且仅影响后续访问，不重算已有 counter
最常被忽略的一点：LFU 的抗污染能力高度依赖业务侧的 key 命名与 TTL 设计。算法再精巧，也救不了那些本该 5 分钟后就消失却硬生生活了 7 天的 tmp: key。
