Redis LFU计数器自动衰减原理与lfu-decay-time解析

许多人误以为 Redis 的 LFU 计数器会按照固定时间间隔自动衰减，但真正的机制其实是一种“按需触发、直到最后一刻才执行”的懒加载设计。经常被误解的 lfu-decay-time 配置项，本质上控制的是检查时机，而不是一个定时器节奏。

lfu-decay-time 并非倒计时器，而是检查窗口

该参数的单位是“分钟”，但它并不意味着“每隔 1 分钟就自动对所有 key 的 logc 减一”。实际的衰减只会在以下两个时机发生：

• 当某个 key 被访问之前，Redis 会先判断：距离该 key 上一次被访问，是否已经过去了 lfu-decay-time 分钟？如果条件满足，则立即对它执行一次右移 1 位的操作（即除以 2 并向下取整）。
• 在内存淘汰过程中，如果该 key 恰好被采样到，也会顺便进行一次衰减检查。

换句话说，一个长期未被访问的 key，它的 logc 可能几个月都保持不变，直到下一次被访问或采样时才突然衰减。这并非 Bug，而是 Redis 在性能方面主动做出的一个取舍——采用懒加载优化策略。

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

OBJECT FREQ 命令返回的仅仅是当前内存中 logc 的静态快照，它完全不会包含“未来应该执行但尚未执行的”衰减。典型的误解场景是这样的：

• 你刚 SET 一个 Key，OBJECT FREQ 返回 5，这很正常，因为初始值就是 5。
• 过了两分钟再去查询，还是 5——无需惊讶，因为这个 Key 从未被访问或采样，衰减从未被触发。
• 此时你 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 在性能和精度之间主动做出的权衡——它并不打算保证单个 key 的严格单调衰减，只要求整个淘汰倾向符合“低频优先”的统计规律。

真正难调的，不是 lfu-decay-time 本身，而是它与 lfu-log-factor 之间的协同效应。前者控制“多久降一次”，后者控制“每次降完之后还能不能涨上去”。两者配合调整，才能真正影响冷热边界线的实际位置。前者是调度，后者是量级，后者才是真正的胜负手。