Redis 6.0才支持LFU但默认仍是LRU需显式配置maxmemory-policy为volatile-lfu或allkeys-lfu才生效OBJECT FREQ返回8位对数频次0–255非精确访问次数LFU衰减和增长受lfu-decay-time与lfu-log-factor影响需按业务调优。LFU在Redis里不是默认启用的Redis 6.0 才正式支持 lfu 淘汰策略但默认仍是 lru。想用LFU必须显式配置 maxmemory-policy 为 allkeys-lfu 或 volatile-lfu否则哪怕版本够新也完全不生效。常见错误是只升级Redis却没改配置结果观察 OBJECT FREQ 返回值始终为0——那是因为LFU统计根本没开。检查当前策略CONFIG GET maxmemory-policy临时切换重启后失效CONFIG SET maxmemory-policy volatile-lfu永久生效在 redis.conf 中写入 maxmemory-policy volatile-lfuOBJECT FREQ返回值不是访问次数而是对数频次OBJECT FREQ 查看的是LFU的内部计数器它用8位存储0–255且采用对数增长低频访问时增量明显高频后增长极慢。比如1次访问可能是110次可能是10但100次可能还是121000次可能才到17。这设计是为了防止计数器溢出也降低更新开销但容易让人误判“这个key明明被狂刷怎么freq还不涨”。别拿它当精确计数器用只适合做相对热度比较。执行 OBJECT FREQ mykey 前确保该key最近被访问过LFU计数器只在访问时按概率更新刚写入的keyOBJECT FREQ 可能返回0不代表没被记录只是还没触发首次衰减或提升如果需要真实访问统计得自己用 INCR 过期时间模拟Redis不提供原生计数LFU衰减周期和counter-log-base影响实际淘汰行为LFU有两个关键配置项lfu-decay-time单位分钟控制计数器衰减频率lfu-log-factor默认10影响对数增长曲线斜率。它们不写进配置文件就用默认值但默认值在高并发场景下常导致“冷热混杂”——老热点因衰减过快被误删新突发流量又顶不上去。 WisPaper 复旦大学研发的AI学术搜索工具5分钟内筛选1000篇论文