Redis LFU频率计数为什么不等于精确访问次数

我第一次用 OBJECT FREQ 看缓存热点时，也会下意识把返回值当成“这个 key 被访问了多少次”。但 Redis 的 LFU 计数并不是访问日志：它是给淘汰策略排序用的、带衰减的对数近似值。所以业务日志里记录了 1000 次访问，OBJECT FREQ 可能只显示一个远小于 1000 的整数；一段时间没有访问后，这个数还可能变小。

先记住结论：OBJECT FREQ key 适合判断“哪个 key 相对更热”，不适合回答“这个 key 在某个时间段精确访问了几次”。

官方文档：https://redis.io/docs/latest/commands/object-freq/

OBJECT FREQ 返回的到底是什么

OBJECT FREQ 的时间复杂度是 O(1)，返回 Redis 对象的 logarithmic access frequency counter，也就是对数形式的访问频率计数。它只有在 maxmemory-policy 采用 LFU 策略时才可用；key 不存在时返回空值。

# 只有 LFU 淘汰策略下，OBJECT FREQ 才有对应的计数语义
redis-cli CONFIG SET maxmemory-policy allkeys-lfu

# 读取指定 key 的近似频率；返回整数，不要直接解释成累计访问总数
redis-cli OBJECT FREQ cache:user:42

这里的“频率”服务于淘汰决策：当内存达到 maxmemory 限制时，Redis 会在候选 key 中倾向于淘汰低频对象。因此它更像一个紧凑的排序信号，而不是一个为报表设计的计数器。

为什么访问 1000 次，计数却不是 1000

Redis LFU 使用 Morris counter 一类的概率计数方法，用很少的位数保存频率信息。每次访问并不保证让计数器加一，而是根据当前计数值和配置的对数因子决定是否递增。计数值越高，继续递增所需的访问次数通常越多，这样才能在有限空间里同时区分低频和高频 key。

这会带来三个直观结果：

• 低访问量阶段，几次访问可能让数值变化比较明显。
• 高访问量阶段，很多次访问可能只带来一次递增，计数器最终还会饱和。
• 不同 key 即使真实访问总数不同，只要热度等级接近，近似计数也可能相同。

官方文档说明这个计数器的范围是 0 到 255，默认设置下大约在百万次请求量附近饱和。这个范围足够用于“相对热度”比较，却不可能保留完整的访问次数。

衰减会让旧的热 key 重新变冷

如果计数只增不减，几天前的热点会一直压过刚刚变热的 key，淘汰结果就无法适应流量变化。因此 LFU 还会让长期没有访问的对象逐步衰减。默认情况下，Redis 的衰减时间为 1 分钟；准确地说，当对象被采样并发现已经超过衰减周期时，计数才会按规则减少，并不是一个后台线程每分钟遍历所有 key。

这也是另一个常见误区：OBJECT FREQ 不是“从 Redis 启动到现在的累计值”。它表示带时间记忆的当前热度估计。昨天的爆款 key 今天可能和普通 key 接近，这往往是设计目标，而不是计数丢失。

先确认你的实例真的启用了 LFU

排查时我会先看策略，再读计数。因为使用 allkeys-lru、volatile-ttl 或 noeviction 时，不能把 OBJECT FREQ 当成正常的 LFU 指标来解释。

# 查看当前实例的淘汰策略；结果应是 allkeys-lfu 或 volatile-lfu
redis-cli CONFIG GET maxmemory-policy

# 查看 LFU 的两个关键参数，避免把不同实例的数值直接横向比较
redis-cli CONFIG GET lfu-log-factor
redis-cli CONFIG GET lfu-decay-time

# 确认 key 存在后再读取频率；不存在时 OBJECT FREQ 返回空值
redis-cli EXISTS cache:user:42
redis-cli OBJECT FREQ cache:user:42

allkeys-lfu 会在所有 key 中使用近似 LFU，volatile-lfu 只在设置了过期时间的 key 中使用近似 LFU。若线上同时放了缓存数据和持久数据，策略边界会直接影响你对计数的解释。

两个配置项分别改变什么

lfu-log-factor 决定计数器在低频和高频区间的分辨率与饱和速度。因子越高，达到高计数值需要更多访问；因子较低时，低访问量差异更容易被区分，但高频 key 更早接近上限。官方默认值是 10。

lfu-decay-time 使用分钟作为时间尺度，决定多久没有被访问后，采样时会认为旧计数需要衰减。值为 0 表示不衰减。它不是“每隔多少分钟把全部 key 减一”，而是访问和采样路径上的惰性处理。

精确统计应该把数据放在哪里

如果问题是“这条缓存最近 5 分钟被读取了多少次”，可以在应用层用独立计数 key、消息流或指标系统记录；如果问题是缓存整体命中率，可以结合 INFO stats 中的 keyspace_hits 和 keyspace_misses 计算整体比例。两者都和单个 key 的 LFU 频率不是同一个口径。

# 查看整体命中与未命中统计；它们是实例级指标，不是某个 key 的 OBJECT FREQ
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'

# 业务需要精确次数时，用独立计数 key；计数用途和缓存淘汰用途分开
redis-cli INCR metric:cache:user:42:reads

独立计数也有代价：它会增加写放大、内存和清理工作，分布式场景还要考虑时间窗口与聚合方式。但这些代价是可见、可设计的，比拿近似淘汰信号冒充审计数据更稳妥。

三个问题可以这样判断

OBJECT FREQ 越大，就代表访问次数一定越多吗？

只能在相同实例、相同配置和相近时间窗口内把它当作热度参考。它是概率计数并会衰减，不能据此证明两个 key 的精确访问次数关系。

为什么同一个 key 反复读取，FREQ 有时不变？

概率递增、计数上限和惰性衰减都会造成“读取发生了，但显示值没变”。这正是压缩计数器换取低内存开销的结果。

能不能把 lfu-decay-time 设为 0 获得更准确的累计数？

不能。设为 0 只是关闭衰减，概率递增和 0 到 255 的有限范围仍然存在，最终依旧不是精确累计访问数。

总结

Redis LFU 的目标是用很小的存储成本，持续估计 key 的相对访问热度，并帮助淘汰策略适应热点变化。OBJECT FREQ 返回的是对数近似计数，受概率递增、255 上限、lfu-log-factor 和 lfu-decay-time 影响。因此，淘汰决策看它，精确访问统计看日志或独立指标；把这两种用途分开，看到“计数对不上”就不会误判成 Redis 数据异常。