Redis LFU 淘汰怎样理解计数器衰减

Redis LFU 的计数器衰减，是让过去的访问热度逐渐失去权重，方便缓存适应热点变化。它不是每访问一次必加一，也不是每到一个周期就把全部键的计数减半。以 Redis 8.6 实现为例，衰减按经过的完整周期减去计数，最低到零，并在需要评估时计算。

官方地址：https://redis.io/

下面面向已采用 LFU 的缓存实例，给出读取、调整和回退的处理方法。命令未在本文环境运行，没有实测命中率、计数曲线或性能提升；修改配置的示例仅供隔离测试，不应直接用于未知生产实例。

旧热点迟迟不退时先看三项信号

如果旧热点不再使用，却似乎仍占据缓存，先确认三个信号：当前是否为 LFU 策略、实例是否确有内存淘汰压力、业务热点是否真的已经变化。键还在内存里，不等于衰减没有发生；计数降低也不等于键必须马上被删除。

# 读取实际策略和内存限制，不能从应用配置文件猜服务端现值
redis-cli CONFIG GET maxmemory-policy
redis-cli CONFIG GET maxmemory

# 保留衰减、增长和采样设置，作为变更前记录
redis-cli CONFIG GET lfu-decay-time
redis-cli CONFIG GET lfu-log-factor
redis-cli CONFIG GET maxmemory-samples

# 读取同一实例的内存与累计统计
redis-cli INFO memory
redis-cli INFO stats

allkeys-lfu 的候选范围覆盖全部键；volatile-lfu 只在有过期时间的键中选择。如果目标键没有 TTL，它在后者下不属于同一候选范围，调衰减参数不能改变这一点。CONFIG 可能受 ACL 或托管服务限制，遇到拒绝时按平台入口读取，不建议为一次排障放开全部管理权限。

把概率增长与惰性衰减分开理解

LFU 频率是 0–255 范围的概率近似值，不是累计请求次数。lfu-log-factor 影响增长难度；计数越高，继续增加通常越不容易。把一次 OBJECT FREQ 的返回值直接解释成“访问了多少次”，会把估计值当成业务计量。

lfu-decay-time 的单位是分钟，值越小，在相同无访问时长下可经历更多衰减周期；0 表示不衰减，而不是最快衰减。在 8.6 的 LFUDecrAndReturn 中，完整周期数由经过分钟数除以参数值计算，再从原计数扣减，且不低于零。因此不能照搬“周期性减半”的说法。

为了理解公式，可以假定某个存储计数为 12，经过 6 个可计入的分钟且期间没有访问更新：周期值为 2 时，减 3 得 9；周期值为 1 时，减 6 得 6。这只是算术示意，不是实际 Redis 采样输出；真实访问会改变计数和时间基准。

实现中的衰减函数返回估算值，但本身不直接写回对象字段；真正访问时再显式更新状态。淘汰采样也会使用衰减估算。所以“惰性”指按需计算，不是说冷键必须再次收到 GET 才能降低淘汰评估热度。

只改一个参数并保留原配置

把问题收窄到“历史热度保留太久”后，优先只试 lfu-decay-time。不要同时改 maxmemory、淘汰策略、增长因子和采样数，否则无法区分结果由哪个变更引起。

下面假定隔离实例已经处于 LFU，且实际读取的原值确实是 2，准备试验 1。数字仅示范变更与回退，不是通用推荐值。

# 前提：已记录本隔离实例原值为2，只试验缩短一个衰减周期
redis-cli CONFIG SET lfu-decay-time 1

# 读取当前设置，确认本次修改作用于预期实例
redis-cli CONFIG GET lfu-decay-time

# 观察一个真实存在的测试键；不存在会返回空值
redis-cli OBJECT FREQ demo:lfu:sample

OBJECT FREQ 仅在 LFU 策略下提供相应信息。在 8.6 的实现中，它读取时会调用衰减估算，查键本身使用不触碰访问元数据的路径；但业务的正常读取仍会影响热度，因此不要额外用高频 GET“探活”后再声称观测的是完全冷键。

观察期应覆盖计划讨论的热点切换与若干衰减周期，保存实际业务请求分布。短暂等待后一次读数没有变化，并不能证明参数无效。

回退配置不能找回已淘汰的键

如果变更后命中下降、回源压力增大，先恢复原参数，再观察恢复后的独立窗口。仍以上节原值确为 2 的隔离实例为例：

# 仅适用于先前明确记录原值为2的示例实例
redis-cli CONFIG SET lfu-decay-time 2

# 确认回退值，并重新收集统计基线
redis-cli CONFIG GET lfu-decay-time
redis-cli INFO stats

回退是恢复配置，不是恢复历史状态：已经淘汰的键不会因参数改回而复活，访问更新后的热度也不会还原到变更前。需要回源重建的缓存应有容量保护，不要在回退时无差别预热所有键。

运行时设置与部署配置的持久化另行管理。确认最终采用哪个值后，通过既有配置发布流程保持一致；不要把一次临时 CONFIG SET 当作全部节点和重启后的永久配置。

用同窗口指标判断是否改善

比较变更前后的同长度窗口，记录 keyspace_hits、keyspace_misses、evicted_keys、expired_keys 的增量，同时观察应用延迟与回源负载。缓存命中率可按 Δhits / (Δhits + Δmisses) 计算；分母为零就不计算，遇到实例重启或计数重置则重新建立基线。

INFO stats 给出实例级统计，不等于单个业务的命中率。若多个应用共用实例，应结合应用自身数据拆分；也不能仅凭 evicted_keys 增加就认定衰减更合理。淘汰是在内存压力下发生，过期则由 TTL 语义决定，二者不能混为同一原因。

LFU 仍是近似采样，不保证每次都选全库计数最低的键。只有确认候选范围和压力条件合理后，才考虑采样精度与 CPU 的取舍，不能指望单调一个衰减参数解决所有缓存抖动。

复盘时记录负载变化而不是猜计数

把衰减设为 0 能保护当前热点吗？

0 是关闭衰减，会让历史热度更难被遗忘；它不是针对当前热点的定向保护开关。

计数为 0 会立即删除键吗？

不会把计数直接当 TTL。是否淘汰还受压力、策略和采样选择影响。

可以从 LRU 切到 LFU 后立刻比较吗？

不宜把刚切换的访问元数据视为稳定 LFU 基线。官方实现明确提示这两类元数据需要时间适应；应单独评估策略迁移，不与本次衰减调整混在一起。

参考：Redis 淘汰策略、Redis 8.6 LFU 实现、OBJECT FREQ、OBJECT 观测实现、INFO。