Redis LFU策略验证方法：CLI访问Key看对象频次分

Redis的LFU（最不经常使用）淘汰策略通过8位频次计数器（0–255）动态评估key的访问热度，其核心验证方法是利用`OBJECT FREQ`命令观察同一key在多次GET操作后频次值是否近似上升——但需注意该频次非线性增长、存在周期性衰减、依赖`serverCron`定时更新，且仅在Redis ≥ 4.0、正确配置`maxmemory-policy`（如`allkeys-lfu`或`volatile-lfu`）、设置`maxmemory`并产生真实内存压力的前提下才有效激活；若频次始终为0或无变化，往往源于版本不符、策略未生效、key无过期时间（导致`volatile-lfu`退化）、未达更新时机或客户端限制等常见陷阱，掌握这些细节才能真正确认LFU是否按预期运行。

用 OBJECT FREQ 查看 Key 的 LFU 频次是否变化

Redis 的 LFU（Least Frequently Used）淘汰策略依赖每个 key 内部维护的 8 位频次计数器（0–255），这个值不会直接暴露，但可通过 OBJECT FREQ 命令读取。它返回的是一个近似访问频次，不是精确计数，也不重置为 0，而是随衰减周期缓慢下降。

验证 LFU 是否生效，最直接的方式就是：对某个 key 执行多次读操作（如 GET），再用 OBJECT FREQ 观察返回值是否上升：

SET mykey "hello"
GET mykey
GET mykey
GET mykey
OBJECT FREQ mykey  # 多次执行后，应看到返回值从 0 → 1 → 2 → 3 或更高（上限 255）

• OBJECT FREQ 只对当前存在且未被删除的 key 有效；如果 key 已过期或被 LRU/LFU 淘汰，命令会报错 (error) ERR no such key
• 频次增长不是线性的：前几次访问可能只涨 1，之后需更多访问才能+1，这是 LFU 的概率性增量设计，避免高频 key 过早“锁死”在高分段
• 若始终返回 0，先确认 Redis 版本 ≥ 4.0（LFU 自 4.0 引入），并检查 maxmemory-policy 是否设为 allkeys-lfu 或 volatile-lfu

为什么连续 GET 后 OBJECT FREQ 不变

常见现象是反复执行 GET + OBJECT FREQ，但返回值卡在 0 或 1 不动。这不是 bug，而是 LFU 频次更新有延迟和条件限制：

• 频次只在「serverCron」周期中更新（默认每 100ms 一次），且仅对最近被访问、且频次计数器未达饱和的 key 触发增量计算
• 若 key 是刚 SET 的，首次 GET 可能不立即触发频次记录，建议至少间隔 100ms 再查，或用 DEBUG SLEEP 0.1 模拟等待
• 使用 redis-cli --raw 模式时，OBJECT FREQ 返回值可能被截断或解析异常，建议去掉 --raw，用默认响应格式
• 某些客户端（如 Jedis、redis-py）默认禁用 OBJECT 类命令，需显式开启或换用原生命令接口

CONFIG GET maxmemory-policy 和实际淘汰行为不一致？

即使 CONFIG GET maxmemory-policy 返回 volatile-lfu，也不代表 LFU 一定在起作用——前提是有 key 设置了过期时间（EXPIRE / PEXPIRE）。否则，所有 key 都被视为“永不过期”，volatile-lfu 实际退化为不淘汰。

• 测试时务必搭配 EXPIRE mykey 3600 使用，让 key 进入 volatile 集合
• 想全局启用 LFU，应设为 allkeys-lfu，此时无论是否有过期时间，所有 key 都参与 LFU 竞争
• 注意 maxmemory 必须已设置（如 CONFIG SET maxmemory 100mb），否则淘汰策略根本不会触发
• 用 INFO memory 查看 mem_allocator 和 used_memory，确认内存压力真实存在（接近 maxmemory），否则 LFU 不会启动淘汰逻辑

用 MEMORY USAGE 辅助判断 LFU 开销是否异常

LFU 比 LRU 多存一个 8 位计数器，理论上每个 key 多占 1 字节，但实际因内存对齐和内部结构，可能多出几个字节。若发现 key 内存占用明显高于预期，可对比 LFU 和 LRU 下的差异：

SET testkey "a"
MEMORY USAGE testkey        # 记录 baseline
CONFIG SET maxmemory-policy allkeys-lfu
# ……大量访问后
MEMORY USAGE testkey        # 再查，通常变化极小（≤ 8B）

• 若 MEMORY USAGE 增长超过 16 字节，大概率是 key 的 value 本身变大了，或被其他机制（如 lazyfree）影响，和 LFU 无关
• OBJECT FREQ 返回值本身不占用额外内存，它只是解码已有字段，所以不要指望通过内存变化反推频次
• 生产环境慎用 OBJECT 命令批量扫描，它在大 key 上可能阻塞主线程；验证阶段只查少量 key 即可

LFU 的频次不是日志，也不持久化——重启后全部归零；它的价值在于运行时动态排序，而验证的关键，是观察「访问→频次上升→淘汰倾向增强」这一闭环是否成立。别盯着单次 OBJECT FREQ 结果，多试几次、等一等、配对检查策略和数据状态，比什么都管用。

到这里，我们也就讲完了《Redis LFU策略验证方法：CLI访问Key看对象频次分》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！