LFU策略会将无TTL key纳入淘汰范围，导致冷数据（如启动加载的配置）因计数器恒为1而被误删；其对数衰减机制使伪热点快速失效，不适用于突发流量场景。
LFU策略对无TTL key的淘汰行为会彻底改变
如果你当前用的是 volatile-lru 或 volatile-lfu，但业务中存在大量未设 TTL 的 key（比如配置项、用户基础信息），切换到 allkeys-lfu 后，这些 key 就会进入淘汰候选池——而它们原本是“免疫”的。LFU 会统计访问频次，但冷数据（比如只在启动时加载一次的配置）计数器始终为 1，一旦内存紧张，极易被误杀。
常见错误现象：evicted_keys 指标突增，但 expired_keys 几乎不变；监控里发现一批长期稳定的 key 频繁消失，业务日志出现大量缓存 miss 回源。
- 检查方式：用
INFO memory对比used_memory和mem_clients_normal，再结合KEYS *抽样查看 key 的 TTL（TTL keyname返回-1表示无 TTL） - 关键动作：先用
redis-cli --scan --pattern "*"扫描无 TTL 的 key 分布，确认占比是否超过 20% - 风险点：Spring Boot 中用
redisTemplate.opsForValue().set("key", "val")默认不设 TTL，这类 key 在volatile-*下永不淘汰，切到allkeys-*后立刻暴露
LFU的counter衰减机制会让“伪热点”短期失效
Redis 的 LFU 不是简单累加计数器，而是用了带衰减的对数增长模型：counter = log(C) + rand(0,1)，且每分钟自动衰减一次。这意味着：一个 key 在 1 秒内被访问 100 次，counter 可能只涨到 5～6；但如果接下来 10 分钟没访问，它的 counter 会被大幅拉低，再被访问时又得重新“爬升”。
使用场景：适合长期稳定高频访问（如商品详情页缓存），但对突发流量型热点（如秒杀预热、运营弹窗曝光）不友好——刚刷上去的热度，几分钟后就掉出淘汰池前端，可能还没来得及服务完全部请求。
- 参数影响：
lfu-log-factor控制 counter 增长斜率，值越大，高频访问提升越平缓；lfu-decay-time控制衰减周期（单位：分钟），默认 1，调大可缓解“热度蒸发”过快 - 验证方法：用
OBJECT FREQ keyname查看当前 counter 值，连续调用几次后再隔 2 分钟重查，观察是否明显下降 - 容易踩的坑：把 LFU 当成“永久保活”，结果发现缓存穿透率反而上升，本质是误判了业务访问的时间分布特征
切换策略本身不触发即时淘汰，但会改变后续所有写入决策
执行 CONFIG SET maxmemory-policy allkeys-lfu 是原子操作，不会立刻删 key，也不会重建内部结构。但下一次写入触发内存检查时，Redis 就会按新策略采样、计算、淘汰——也就是说，风险不是“切的时候爆”，而是“切完第一次压测/高峰时爆”。
性能影响：LFU 比 LRU 多一次 counter 更新和衰减判断，单次访问 CPU 开销略高；但在 4.0+ 版本中，这部分已被优化到微秒级，通常感知不到。真正影响吞吐的是淘汰阶段：LFU 需要扫描更多样本才能找到低频 key，maxmemory-samples 值相同时，LFU 实际比较次数比 LRU 多约 1.5 倍。
- 建议配对调整：
maxmemory-samples从默认 5 提到 10，可提升 LFU 选 key 精度，但会略微增加淘汰延迟 - 必须同步检查：
INFO stats中的evicted_keys和total_commands_processed比值，若切换后该比值翻倍，说明淘汰压力已显著上升 - 不要忽略主从差异：从节点不参与淘汰，但会同步主节点发来的 DEL 命令；如果主节点因 LFU 淘汰过快，从节点可能短暂出现“缓存比主还全”的假象，掩盖问题
LFU在混合读写负载下容易放大缓存雪崩风险
LRU 至少保留“最近访问过”的数据，哪怕只访问一次；LFU 却可能把只访问过一两次的 key 视为“低频”，优先淘汰。当业务中存在批量写入+少量随机读的模式（如订单履约系统写入履约状态，客服后台偶尔查单），LFU 会快速清掉那些“写多读少”的 key，导致读请求直接穿透到 DB。
更隐蔽的问题是：LFU 对 key 的“访问”定义仅限于 GET、HGET 等读命令，不包括 SET、EXPIRE 等写命令。所以一个 key 被高频更新但极少读取（如实时计数器），在 LFU 下 counter 几乎不涨，极易被淘汰——而你根本意识不到它正在被“静默清除”。
- 排查要点：对比
INFO commandstats中cmdstat_get和cmdstat_set的调用量级，若后者远大于前者，LFU 就不适合 - 折中方案：用
volatile-lfu+ 统一给所有 key 设置较短 TTL（如 1 小时），既利用 LFU 识别真实热点，又靠 TTL 保障兜底存活 - 最易被忽略的一点：LFU 的“频率”统计不区分客户端来源，一个定时任务每分钟扫一遍全量 key，会把所有 key 的 counter 都拉高，让真正业务热点失去区分度
