为何Redis的LFU计数器会自动衰减_解析lfu-decay-time的工作原理

Redis LFU计数器按需衰减而非定时衰减，衰减仅在key被访问或采样时触发，由lfu-decay-time控制检查时机；OBJECT FREQ返回当前logc快照，不包含待执行衰减；调小该值会引发震荡、误判与性能开销；衰减非原子操作，多线程下结果不可预测。

Redis的LFU计数器不是“自动定时衰减”，而是按需触发、延迟执行的——lfu-decay-time 控制的是衰减时机，不是衰减节奏。

lfu-decay-time 触发的是“检查窗口”，不是“倒计时器”

这个配置项（单位：分钟）只决定 Redis 什么时候“愿意去算一算该不该衰减”，而不是每过这么多分钟就无条件执行一次 -1。实际衰减发生在两个时刻之一：

• 某个 key 被访问前，Redis 会先检查：距它上一次访问是否已满 lfu-decay-time 分钟？如果是，就立刻对它的 logc 执行一次右移 1 位（即除以 2 向下取整）
• 内存淘汰采样时，如果该 key 被抽中，也会顺带做一次衰减检查

这意味着：一个长期没人碰的 key，它的 logc 值可能几个月都不变——直到下一次被访问或被采样到才衰减。这不是 bug，是设计上的懒加载优化。

为什么 OBJECT FREQ 查不到实时衰减值

OBJECT FREQ 返回的是当前内存里存着的那个 logc 快照，它不包含“未来待执行的衰减”。常见误解场景：

• 刚 set 一个 key，OBJECT FREQ 返回 5 → 正常，初始值就是 5
• 等了 2 分钟再查，还是 5 → 因为它没被访问/采样，衰减根本没触发
• 此时你 get 一下它，再查 OBJECT FREQ，大概率变成 2（5 >> 1）→ 衰减在 lookupKey 前就完成了

所以别用 OBJECT FREQ 判断“衰减是否准时”，而要用“访问前后对比”来验证逻辑是否生效。

调小 lfu-decay-time 反而会让 LFU 更不准

把 lfu-decay-time 从默认 1 改成 0.1（6 秒），看似更灵敏，实则引入三重风险：

• 高频 key 在并发访问下可能被反复衰减+概率 +1，导致 logc 震荡（比如 10 → 5 → 6 → 3）
• 低频 key 的 logc 被削得太快，刚涨到 3 就被衰减到 1，容易和真正冷数据混淆
• 衰减检查本身有开销，频繁触发会增加 lookupKey 的平均延迟（尤其在大 key 空间中）

官方建议保持默认 1 分钟；只有当你明确需要区分“小时级热度变化”（如突发新闻类缓存），且观察到 INFO memory 中 lfu_bypassed 显著升高时，才考虑下调，并同步调大 maxmemory-samples 至 10+ 提升采样稳定性。

衰减不是原子操作，竞争下结果不可预测

多个线程同时访问同一个 key 时，衰减和计数更新可能交错发生。例如：

• T1 线程读到 logc = 10，判断需衰减 → 执行 10 >> 1 = 5
• T2 线程几乎同时读到 logc = 10，也执行衰减 → 再次写入 5
• 接着 T1 概率 +1 成功 → 写入 6
• T2 也概率 +1 成功 → 写入 6（覆盖了 T1 的结果）

最终值仍是 6，但中间两次衰减只生效了一次。这种非确定性是 Redis LFU 在性能与精度之间做的主动取舍——它不保证单 key 的严格单调衰减，只保障整体淘汰倾向符合“低频优先”的统计规律。

真正难调的不是 lfu-decay-time 的数值，而是它和 lfu-log-factor 的协同效应：前者管“多久降一次”，后者管“每次降完还涨不涨得上去”。两者一起动，才会影响冷热边界的实际位置。