Redis OBJECT FREQ 如何判断热点键：编码类型、采样结果与淘汰策略

缓存命中率突然掉下来时，先别急着把所有键导出来做排行榜。对正在使用 LFU 淘汰策略的 Redis 实例，可以先对一个可疑键运行 OBJECT FREQ，再用 OBJECT ENCODING 和 INFO stats 补齐证据，判断它是访问频繁、数据结构异常，还是只是刚好被流量撞上。

OBJECT FREQ 适合回答“这个键的访问频率计数大不大”，不负责回答“全库最热的键是谁”。只有在确认实例使用 LFU 策略、并结合命中率与淘汰行为复核后，才适合把它作为缓存决策依据。

线上排查先分清三个问题

同一个 session:8421 键，运维同学可能同时问三件事：它被访问得多不多、Redis 用什么结构保存它、整个缓存的命中率是否正在恶化。三个问题的答案分别来自 OBJECT FREQ、OBJECT ENCODING 和 INFO stats，混用命令会让排查结论跑偏。

我更建议先固定一个键和一个时间窗口。单次频率读取可以帮助确认方向，却不能替代一段时间的业务指标。

用 OBJECT FREQ 看单键访问频率

在启用 LFU 相关策略的实例上，可以执行：

redis-cli OBJECT FREQ session:8421
redis-cli OBJECT ENCODING session:8421

第一条命令返回该对象的对数访问频率计数；键不存在时会得到空结果。第二条命令返回内部编码，例如字符串可能是 int、embstr 或 raw。这两个返回值都属于单键证据，不能据此推断整个数据库的热度排序。

为什么频率数字不能直接当访问次数

LFU 频率计数采用对数增长并会衰减，数值的用途是让淘汰策略比较相对热度，而不是记录精确点击次数。因此不能把返回值 10 解读成“访问了十次”，也不能拿两个不同实例、不同观察阶段的数字直接横比。

把单键证据放回 INFO stats

单键频率看起来正常，但命中率仍然下降，下一步看统计窗口：

redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'

keyspace_hits 是成功找到键的次数，keyspace_misses 是主字典查找失败的次数。用两者计算命中比例时，必须记录开始和结束值，不能把 Redis 重启前后的累计值混在一起。

如果业务刚发布了新的键前缀，命中率下降未必说明 session:8421 变冷。先按业务前缀、实例和时间段拆分，再回到单键验证，排查会更稳。

从观察结果决定是否采用 LFU

OBJECT FREQ 真正有价值的场景，是实例已经明确使用 LFU 淘汰策略，需要解释某个键为什么更可能留下或被淘汰。可以先核对 maxmemory-policy，再观察频率、命中率和淘汰计数是否同向变化。

如果实例使用的是 allkeys-lfu 或 volatile-lfu，频率计数可作为理解淘汰顺序的线索；如果使用 allkeys-lru、volatile-ttl 或 noeviction，则不要用它解释实际淘汰结果。策略变更还会影响大量键，应该先在容量和流量相近的环境做对照。

三个容易误判的边界

• 把 OBJECT ENCODING 当热度。 embstr 和 raw 描述内存编码，不表示键更热或更冷。
• 把单键命令当全库扫描。 OBJECT FREQ 一次只读一个键，不会生成热点榜单；全库扫描还可能带来额外负载。
• 只看累计命中率。 发布、扩容、重启或键空间切换后，累计指标失去可比性，应该重新建立窗口。

相关问题

OBJECT FREQ 返回空值怎么办？

先确认键仍存在，再检查实例是否支持该命令以及是否处在可读取该对象统计的配置路径上。空值不能直接解释为“访问频率为零”。

OBJECT FREQ 能找出全库最热键吗？

不能。它是针对单键的 O(1) 查询，需要结合业务已知键、采样或其他观测手段定位候选。

OBJECT ENCODING 变化代表键被频繁访问吗？

不代表。编码变化通常与值类型或大小变化有关，应与数据写入路径和内存观察一起判断。

结论：先证实热度，再谈淘汰

排查热点键时，推荐顺序是：先用 OBJECT FREQ 检查具体候选，再用 OBJECT ENCODING 解释存储形态，最后用 INFO stats 和实际 maxmemory-policy 验证整体表现。这样得到的是一条可复查的证据链，而不是把一个计数值包装成全库结论。