allkeys-lru在高并发下缓存命中率低，因其仅依据最后一次访问时间淘汰，忽视长期高频访问模式；秒杀等场景中，新key涌入易挤出稳定高频key。切换lfu前须确认：redis≥6.0、maxmemory-policy已设为lfu策略、maxmemory已配置；调优需调整lfu-decay-time和lfu-log-factor参数，并理解object freq返回的是对数频次而非精确计数。
为什么allkeys-lru在高并发下缓存命中率上不去
因为LRU只看“最后一次访问时间”，不区分访问频次。在秒杀、热点新闻等场景中，大量新key瞬间涌入，把原本稳定被访问的高频key（比如用户基础信息、商品详情）挤出缓存——哪怕它们每分钟都被查10次，只要最近1秒没被访问，就可能排在淘汰队列尾部。这不是算法错了，是它压根没设计去识别“长期高频”这个模式。
切换LFU前必须确认的三件事
很多团队切完发现 OBJECT FREQ 全是0，或者命中率毫无变化，问题往往出在这三步没做：
- Redis版本 ≥ 6.0 ——
INFO server查redis_version，低于6.0的LFU只是空壳 -
CONFIG GET maxmemory-policy确认当前策略不是默认的noeviction或allkeys-lru，LFU不会自动启用 -
maxmemory必须已设置（比如2gb），否则淘汰机制根本不会触发，LFU无从谈起
allkeys-lfu配置后仍命中率低？调这两个参数
默认的 lfu-log-factor 10 和 lfu-decay-time 1 是通用值，在QPS过万的业务里常导致“冷热混杂”：老热点衰减太快，新突发流量又涨不上去。真实调优要看业务节奏：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 如果核心数据（如用户token、配置项）需要长期稳住，把
lfu-decay-time调大到60（单位分钟），让计数器1小时才衰减一次 - 如果要更快响应突发流量（比如活动页面），把
lfu-log-factor从10降到5，让低频访问的counter增长更敏感 - 改完立刻生效：
CONFIG SET lfu-decay-time 60，无需重启，但记得同步写进redis.conf
别拿OBJECT FREQ当实时计数器用
OBJECT FREQ mykey 返回的是8位对数频次（0–255），不是真实访问次数。刚写入的key返回0，不代表没记录，只是还没触发概率更新；访问100次后返回值可能才到12，1000次也才17。它只适合横向比热度：“A key的freq=23，B key的freq=5”，说明A大概率比B热。
真要监控精确访问量，得自己用 INCR cache:access:mykey + EXPIRE 模拟，Redis原生不提供这个能力。混淆这两者，会误判LFU是否生效。
