LFU频率计数器非线性增长，由lfu-log-factor和lfu-decay-time共同调控：访问按概率递增且增幅随当前值增大而衰减，初始值为5、上限255；衰减每lfu-decay-time分钟执行一次右移1位。
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 向下取整）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 设为 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 的频率计数器本质上是个带偏置、有损耗、非实时的热度估算器，不是计数器。它的价值不在“准”，而在“相对排序稳定”——这点容易被监控指标或压测报告带偏方向。
