Redis如何快速验证自己配置的LFU策略是否生效_利用cli连续访问特定Key后查看OBJECT频次分-Redis-PHP中文网

object freq 返回 key 的 lfu 近似频次（0–255），多次 get 后应上升；频次非线性增长、有衰减、依赖 servercron 更新，需确认 redis ≥ 4.0、maxmemory-policy 正确配置且内存压力存在。

redis如何快速验证自己配置的lfu策略是否生效_利用cli连续访问特定key后查看object频次分

用 `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 频次更新有延迟和条件限制：

redis-tools

按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。

下载

频次只在「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 结果，多试几次、等一等、配对检查策略和数据状态，比什么都管用。