lfu比lru更适合强热点场景，因其按访问频次而非时间淘汰，配合衰减机制避免历史抖动；需正确配置lfu-log-factor和lfu-decay-time，否则退化为lru；其采样与近似计数导致单次结果不准，但长期趋势可靠。
LFU比LRU更适合有强热点的业务场景
当你的缓存中存在少数key被高频访问（比如商品详情页ID item:10086、用户登录态 session:abc789），而其他key访问稀疏时，LRU容易把刚“热起来”的key误判为冷数据淘汰——它只看最近一次访问时间，不关心频率。LFU则通过统计访问次数，让真正高频的key更难被淘汰。
- 典型场景：电商首页商品缓存、用户权限令牌池、配置中心高频配置项
- 注意：LFU不是“永久保留高频key”，它带衰减机制——旧周期的访问热度会随时间降低，避免历史抖动影响当前决策
- 衰减由配置项
lfu-decay-time控制（单位：分钟），默认1是每分钟将计数器右移1位（即÷2），太小会导致热度流失过快，太大则响应滞后
启用LFU必须改两个关键配置
光在 maxmemory-policy 里设成 allkeys-lfu 或 volatile-lfu 不够，LFU依赖底层计数器，而Redis默认不开启该功能。你得确认：
-
maxmemory-policy已设为含lfu的策略（如volatile-lfu） -
lfu-log-factor和lfu-decay-time至少保留默认值（不注释掉），否则计数器不会初始化 - 错误写法：
maxmemory-policy volatile-lfu+ 注释掉所有lfu-*行 → 实际退化为LRU行为
LFU的随机采样机制导致“看似不准”的淘汰结果
Redis不会遍历全部key更新访问频次，而是在每次访问key时，用概率算法更新其LFU计数器——这意味着：
- 低频key的计数器可能长期为0或1，哪怕被访问过几次；高频key的计数器增长也非线性（受
lfu-log-factor影响） - 淘汰时同样只随机抽
maxmemory-samples个key（默认5个），再从中挑计数最小的删——样本量小，单次淘汰未必精准，但长期统计趋势可靠 - 别拿单次
OBJECT FREQ返回值做绝对判断；它只是近似热度指标，不是精确访问次数
LFU在混合读写负载下可能拖慢写操作
每次写入一个已存在的key（如 SET item:10086 "data"），Redis需更新其LFU计数器，涉及原子加和位运算。相比LRU（仅更新逻辑时间戳），LFU开销略高：
- 实测：在QPS 5万+、key复用率＞70%的写密集型场景，LFU比LRU平均延迟高约0.2~0.4ms
- 若业务对写延迟极度敏感（如实时风控规则缓存），建议压测验证；可临时切回
allkeys-lru对比 - 注意：只读场景下LFU无额外开销，
GET仍为O(1)
OBJECT FREQ 值，而是整体缓存命中率曲线和淘汰key的分布。
