Redis如何调整LFU频率计数器增长速度

Redis的LFU淘汰策略通过非线性、概率化且带衰减机制的频率计数器来估算键的访问热度，其增长并非简单的“访问一次加一”，而是由lfu-log-factor（控制低频键快速响应、高频键增长放缓）和lfu-decay-time（决定衰减触发频率而非幅度）协同调控；新键初始值为5、上限255，既防止冷键被突发流量误判为热点，也避免计数器无限膨胀；它本质上是一个有偏置、有损耗、非实时的相对热度估算器——不追求绝对准确，而重在长期稳定的热度排序，这对理解LFU行为、调优内存淘汰及规避常见误用（如依赖OBJECT FREQ做业务判断或跨节点比热度）至关重要。

LFU频率计数器不是线性增长的

Redis 的 lfu-log-factor 和 lfu-decay-time 共同决定计数器怎么涨、怎么衰减，但很多人误以为“访问一次就 +1”。实际是：每次访问会按概率增加计数器，且增长幅度随当前值变大而递减——这是为了避免高频 key 过早挤掉中频 key。

• lfu-log-factor 越大，低频 key 的计数器越容易“跳涨”（比如从 0→1、1→2 更快），但高频 key 增长明显放缓；默认值 10 是平衡点，调到 100 后，访问 100 次可能才从 5→6
• 计数器最大值固定为 255，一旦达到就不会再增，所以不能靠它精确统计访问次数
• 增长公式本质是：new_counter = old_counter + 1.0 / (factor * old_counter + 1) 的随机化近似（Redis 用查表+随机判断模拟）

为什么刚设置的 key 频率计数器涨得慢

新 key 的初始计数器值是 5（不是 0），这导致第一次增长的概率被压得很低。比如 lfu-log-factor=10 时，初始值 5 对应的增长权重只有约 0.018，意味着平均要访问 55 次才大概率触发一次 +1。

• 这不是 bug，是设计：防止突发流量把冷 key 临时推成“热 key”，干扰淘汰决策
• 如果真需要快速响应新热点（比如秒杀预热），得提前用 OBJECT FREQ + MEMORY USAGE 配合脚本手动 bump 计数器（虽然不推荐）
• 注意 OBJECT FREQ 返回的是当前计数器值，不是访问次数，别拿它做业务逻辑判断

lfu-decay-time 控制的是“多久降一次”，不是“降多少”

这个配置只影响衰减触发频率（单位：分钟），不影响每次衰减的步长。Redis 每隔 lfu-decay-time 分钟扫描一遍所有 key，对每个 key 的计数器执行一次“右移 1 位”（即除以 2 向下取整）。

• 设为 0 表示禁用衰减——计数器只增不减，长期运行后大量 key 会卡在 255，LFU 退化成近似 LRU
• 设为 1 时衰减太频繁，低频 key 容易被误删；生产环境建议从 10 开始试，观察 INFO memory 中 lfu_bypassed 和 evicted_keys 变化
• 衰减不保证原子性：某个 key 在衰减窗口期内被多次访问，可能只被衰减一次，也可能被跳过——这是正常现象

用 OBJECT FREQ 查到的值为什么和预期不符

OBJECT FREQ 返回的是当前内存中的计数器快照，但它受三个隐藏因素影响：后台衰减时机、计数器饱和、以及 Redis 版本差异（6.0 之前无 LFU，6.0+ 才有）。

• 刚 set 的 key，OBJECT FREQ 返回 5，不是 0 —— 别当成 bug 报告
• 如果看到某个 key 长期返回 255，说明它持续高频访问，或 lfu-decay-time 太大导致衰减跟不上
• 集群环境下，OBJECT FREQ 只查本地节点，别跨节点比大小来判断“哪个更热”
• 测试时用 DEBUG SLEEP 10 强制触发一次衰减，再查 OBJECT FREQ，比等真实时间更可控

LFU 的频率计数器本质上是个带偏置、有损耗、非实时的热度估算器，不是计数器。它的价值不在“准”，而在“相对排序稳定”——这点容易被监控指标或压测报告带偏方向。

今天关于《Redis如何调整LFU频率计数器增长速度》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！