Redis LRU 和 LFU 淘汰策略如何按访问特征选择

Redis 的 LRU 和 LFU 都是在 maxmemory 达到上限后帮助缓存腾出空间，但判断依据不同：LRU 看“最近有没有访问”，LFU 看“长期被访问了多少次”。如果热点对象会随时间迁移，通常先考虑 allkeys-lru；如果少数对象长期高频、冷数据很多，allkeys-lfu 更贴合。两者都是近似淘汰，不应把它们当成精确排序器。

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

一、先分清 LRU 和 LFU 保留的是什么

LRU（Least Recently Used）优先淘汰最近最久没有被访问的键。它适合“刚访问过的对象接下来仍可能被访问”的场景，例如页面缓存、短时热点接口和有明显时间局部性的读请求。某个键过去很热门，但一段时间没有再被访问，LRU 会逐步把它视为更合适的淘汰候选。

LFU（Least Frequently Used）记录访问频率，倾向于保留累计访问次数高的键。Redis 的 LFU 不是为每个键维护无限增长的精确计数，而是使用近似计数并随时间衰减，让很久以前的热点不会永久占据优势。因此，LFU 更适合热度差异明显且热点相对稳定的缓存，但不能据此承诺精确的访问排名。

二、按缓存访问特征选择淘汰策略

可以先问三个问题。第一，业务是否存在“刚读过的对象短期还会再读”的时间局部性？如果是，LRU 往往更容易得到稳定结果。第二，热度是否长期集中在少数键上？如果是，LFU 更有机会把高频对象留在内存里。第三，热点是否会快速迁移？如果新品、榜单或活动数据的热度变化很快，LFU 的历史频率可能暂时拖慢淘汰反应，此时应先用 LRU 做基线。

这里的“选择”不是只看命中率。缓存对象大小、回源成本、淘汰后的重建时间也要一起看：若某类对象很大且回源昂贵，保护它们可能更重要；若对象很小但访问极其分散，继续调策略未必比增加容量有效。先记录基线，再用同一流量回放比较命中率、淘汰率和应用延迟。

同一实例内还要注意策略范围。allkeys-lru 和 allkeys-lfu 可以在所有键中寻找候选；volatile-lru 和 volatile-lfu 只看设置了过期时间的键。如果一部分键没有 TTL，误用 volatile 可能导致候选不足，最终表现得像没有可淘汰的键。

三、用 maxmemory-policy 配置并观察结果

下面是配置示意，不代表已经在本机执行。缓存实例可以把内存上限和策略写进配置文件；临时调整则可用 CONFIG SET，但运行时修改不会自动替代重启后使用的配置文件，正式变更要同步维护配置来源。

# 先为缓存实例设置明确的内存上限。
maxmemory 2gb
# 热点稳定时可选择 allkeys-lfu；时间局部性更强时改为 allkeys-lru。
maxmemory-policy allkeys-lfu

观察时不要只看 Redis 是否报错。官方 INFO 输出中的 maxmemory、maxmemory_policy、keyspace_hits、keyspace_misses 和 evicted_keys 可以帮助判断策略是否真的适合当前流量。下面命令同样只是查询示意：

# 查看当前内存上限和实际淘汰策略。
redis-cli INFO memory | grep -E 'used_memory_human|maxmemory|maxmemory_policy'
# 查看命中、未命中与淘汰数量，配合固定时间窗口比较变化。
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys'

如果切换到 LFU 后命中率没有改善，先确认请求分布是否真的有长期频率差异；如果淘汰数暴涨而回源延迟上升，可能是容量太小或对象生命周期与策略不匹配。不要用一次短时观测就断言某个策略永远更好。

四、处理持久数据、TTL 和策略切换边界

如果 Redis 同时保存缓存和不可丢失的数据，优先考虑拆成两个实例或两个明确的数据边界，而不是用 volatile 策略赌所有关键键都会正确设置 TTL。Redis 官方也提醒，给键设置过期时间本身会占用内存；当所有数据本来都属于可重建缓存时，allkeys-lru 不依赖 TTL 作为候选条件，配置更直接。

非缓存工作负载则不应为了“自动清理”盲目开启 LRU/LFU。可以使用 noeviction 让写入在达到上限时返回错误，再由容量规划和告警处理。还要区分逻辑已释放的 used_memory 与进程 RSS：删除键后底层分配器未必立即把内存还给操作系统，不能只凭机器内存曲线判断淘汰策略是否失效。

相关问题

LRU 和 LFU 哪个命中率一定更高？

没有固定答案。命中率取决于访问分布、对象大小、回源成本和容量；应在相同流量窗口中比较命中、未命中、淘汰和应用延迟。

为什么设置了 volatile-lfu 却几乎没有淘汰？

该策略只从设置了 TTL 的键里选候选。如果很多键没有过期时间，候选集合可能不足；纯缓存场景可评估 allkeys-lfu，混合数据则更适合拆分边界。

切换 maxmemory-policy 后需要重启 Redis 吗？

可以用 CONFIG SET 临时调整，但它不会自动改写配置文件。要让重启后的实例保持一致，应同步更新配置来源，或按运维流程使用配置重写。