Redis如何利用LFU算法优化缓存命中率

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次访问可能是1，10次可能是10，但100次可能还是12，1000次可能才到17。这设计是为了防止计数器溢出，也降低更新开销，但容易让人误判“这个key明明被狂刷，怎么freq还不涨”。别拿它当精确计数器用，只适合做相对热度比较。执行 OBJECT FREQ mykey 前，确保该key最近被访问过（LFU计数器只在访问时按概率更新）刚写入的key，OBJECT FREQ 可能返回0，不代表没被记录，只是还没触发首次衰减或提升如果需要真实访问统计，得自己用 INCR + 过期时间模拟，Redis不提供原生计数LFU衰减周期和counter-log-base影响实际淘汰行为LFU有两个关键配置项：lfu-decay-time（单位：分钟）控制计数器衰减频率；lfu-log-factor（默认10）影响对数增长曲线斜率。它们不写进配置文件就用默认值，但默认值在高并发场景下常导致“冷热混杂”——老热点因衰减过快被误删，新突发流量又顶不上去。 WisPaper 复旦大学研发的AI学术搜索工具，5分钟内筛选1000篇论文