LFU算法以访问频率为核心淘汰依据，优先移除使用次数最少的数据；当频率相同时，按最近最久未使用规则淘汰，并引入时间衰减机制提升热度计算的时效性。

LFU（Least Frequently Used）不是靠“最近有没有用”来淘汰，而是看“用得勤不勤”。它把访问次数作为核心指标，次数越少，越早被踢出缓存。但光数次数不够——刚被访问过的冷数据，和三个月前被访问过一次的老数据，热度显然不同。所以真正实用的 LFU 实现，必须把时间衰减加进去，让频次带“时效性”。

频率怎么算才合理？别只加1

简单每次 get/put 就 counter++，会导致老数据长期霸占缓存。Redis 的 LFU 实现就用了对数增长 + 时间衰减：低频访问时 counter 增长快（1→2→3），高频后变慢（100→101→101），避免溢出；同时每过一段时间（比如配置的 decay 时间），自动下调所有 key 的 counter，让沉寂的数据自然降温。

• 新 key 插入时，counter 初始值设为 5（不是 1），避免一进来就被淘汰
• 每次访问调用 LFULogIncr() 更新 counter，曲线近似 √n
• 后台或下次访问时检查 ldt（最后衰减时间），若距今超阈值，执行 LFUDecrAndReturn() 下调 counter

相同频率下怎么选？LRU 是它的兜底规则

两个 key 都只被访问过 1 次，淘汰谁？LFU 明确要求：按“最近最久未使用”来裁决——也就是在同频次组内，走 LRU 逻辑。这意味着你不能只维护一个全局链表，而要按 frequency 分桶，每个频次对应一个双向链表，且链表内部按访问时间排序（头新尾旧）。

• 用 freq → 链表头节点 的哈希映射快速定位各频次段
• 每个节点记录 last_access_time，同频次淘汰时比这个时间戳
• min_freq 变量实时跟踪当前最低有效频次，避免遍历全表找最小

Redis 里怎么配？别直接抄文档参数

Redis 4.0+ 支持 volatile-lfu 和 allkeys-lfu 两种策略。但注意：它复用了原有 lru 字段（24 bit），高 16 位存 ldt（毫秒时间戳），低 8 位存 logc（对数计数器）。这意味着 counter 最大只到 255，且时间精度受限于 ldt 的 16 位表示范围（约 65 秒分辨率）。

• 通过 CONFIG SET maxmemory-policy allkeys-lfu 启用
• 调整 lfu-log-factor 控制增长斜率（默认 10，值越大，高频 key 更难涨上去）
• 设置 lfu-decay-time（单位：分钟），决定多久衰减一次（默认 1，即每分钟衰减）

什么时候该用 LFU？别硬套

LFU 不是万能升级版 LRU。它适合访问模式稳定、有明显热门/冷门分层的场景，比如商品详情页缓存（爆款常年高流量）、用户画像标签（活跃用户标签反复读取）。但对突发流量敏感——一场营销带来大量一次性访问，会把 logc 拉高，挤掉真实长尾热点。

• 日均 PV 百万以上、TOP 100 商品占 70% 流量 → 适合 LFU
• 大量 AB 测试 key、临时活动页、用户上传临时文件 → LRU 或 TTL 更稳
• 不确定时，先用 Redis 的 INFO memory 观察 lfu_hits/lfu_misses，再决定是否切换