Redis LFU 淘汰为什么不按访问次数排序：衰减周期、热点误判与验收

Redis 开启 allkeys-lfu 后，淘汰器并不会把所有键按“真实访问次数”排成一张精确榜单。它使用每个键上的小型概率计数器记录访问热度，再按衰减周期逐步降低旧热点的影响，所以一个曾经很热、最近已经冷却的键，最终仍可能被淘汰。

LFU 的核心不是追求精确计数，而是在很小的额外内存开销下，让长期稳定的热点比短时流量更容易留下；验收时要同时观察策略、计数趋势和淘汰结果。

为什么访问次数高的键仍然可能被淘汰

Redis 的内存淘汰发生在写入让数据超过 maxmemory 之后。此时它从采样得到的候选中挑选低频键，而不是为整个数据库维护一份精确排序。LFU 计数器只有有限位数，访问次数越大，计数增长越慢，避免一个长期热点轻易溢出；同时，老计数会随时间衰减，让访问模式变化后仍有机会淘汰旧热点。

这解释了两个容易混淆的现象：一个刚被突发流量打热的键，不一定立刻成为长期保留对象；一个曾经非常热门但长时间无人访问的键，也不会永远占着缓存。LFU 保护的是持续频繁访问，而不是历史最高访问量。

allkeys-lfu 和 volatile-lfu 先分清范围

如果实例中的每个键都属于可重建缓存，通常先比较 allkeys-lfu 与 allkeys-lru；如果只有带 TTL 的键允许自动清理，才考虑 volatile-lfu。后者在没有足够带过期时间的键时，可能表现得像不淘汰，写入端会先看到内存压力错误。

CONFIG GET maxmemory
CONFIG GET maxmemory-policy
CONFIG SET maxmemory-policy allkeys-lfu

生产环境不要直接把策略切换当成修复动作。先确认持久数据、会话数据和缓存数据是否混在同一个实例，再为策略变更准备回滚值。LFU 只适合“被淘汰后可以重新取得”的数据。

两个参数分别改变什么

lfu-log-factor 决定访问频率映射到概率计数器时的增长速度。因计数器是近似的，同样增加 100 次访问，在低频阶段与高频阶段产生的计数变化并不相同。lfu-decay-time 以分钟表达衰减周期：当键被采样并发现计数已经老于这个窗口时，旧热度会被削弱。

不要仅凭参数名猜效果。最稳妥的做法是固定一组键，分别制造持续热点、短时热点和冷键，再在相同内存上限下重复实验。

用一组可观察的实验验收淘汰行为

先记录基线，再逐步制造内存压力。OBJECT FREQ 在 LFU 策略下可以帮助观察近似频率，但它不是业务访问日志，也不保证数值等于命中次数。

INFO stats
INFO memory
OBJECT FREQ cache:steady
OBJECT FREQ cache:burst
OBJECT FREQ cache:cold

验收至少看三类证据：

1. 策略证据：CONFIG GET maxmemory-policy 返回目标策略，且 maxmemory 不是零或意外的小值。
2. 计数证据：持续热点的频率在多个采样点保持较高，短时热点在等待衰减窗口后不再绝对占优。
3. 结果证据：INFO stats 中 evicted_keys 增长时，应用命中率、数据库回源延迟和错误率没有同步失控。

热点误判时先调整实验，不要急着调大计数

短时活动、定时任务和批量预热会制造“瞬时热点”。如果业务真正需要的是最近一段时间的热度，LRU 可能更贴合；如果热度有明显的昼夜或活动周期，LFU 的衰减窗口要覆盖一个可解释的观察周期。调参前先回答：缓存对象的复用周期是多少，突发流量持续多久，回源一次的代价多大。

还要留意采样误差。提高 maxmemory-samples 可能改善候选质量，但会增加淘汰时的工作量；它不能把近似 LFU 变成精确排名。对于极少数必须长期保留的键，应该改变数据分层或拆分实例，而不是寄希望于淘汰算法“识别例外”。

常见问题

LFU 计数能当作精确访问日志吗？

不能。它是面向淘汰决策的近似频率，适合比较趋势，不适合做计费、审计或精确统计。

volatile-lfu 为什么没有淘汰效果？

它只从带过期时间的键里选候选；如果这类键太少，策略就无法覆盖其他键。先核对 TTL 分布，再判断是否应使用 allkeys 策略。

把 lfu-decay-time 调得很小会更灵敏吗？

会更快忘记旧热点，但也可能让稳定热点失去优势。应以业务复用周期和回源代价为依据，用压测结果决定。

最后的判断清单

• 缓存键是否都允许被重新生成。
• 选择的是全量键淘汰还是仅 TTL 键淘汰。
• 持续热点、短时热点、冷键是否被分别观测。
• 淘汰数增长时，命中率、回源延迟和错误率是否可接受。
• 策略切换是否有明确的旧值、回滚窗口和复核指标。