Redis 内存淘汰策略怎么选：maxmemory、volatile-lru 与缓存命中率验收

线上 Redis 实例的内存告警刚亮起来时，最容易做错的不是把内存调大，而是直接把淘汰策略改成一个听起来“更聪明”的名字。策略真正决定的是：达到 maxmemory 后，Redis 可以从哪些键里找候选，以及新写入无法落下时要不要拒绝请求。

内存告警现场：先确认 Redis 到了哪条边界

先看配置和运行数据，而不是凭感觉改策略。下面几项足以判断当前问题是“没有可淘汰候选”，还是“淘汰太积极导致命中率下降”。

CONFIG GET maxmemory
CONFIG GET maxmemory-policy
INFO memory
INFO stats

used_memory 接近 maxmemory 时，写入路径会受到策略影响；evicted_keys 持续增加说明发生了主动淘汰，但它本身不代表策略选对了。若策略是 noeviction，达到上限后新写入会返回错误，已有键不会自动消失。

淘汰范围怎么定：allkeys 和 volatile 不是同一件事

策略名可以拆成两部分看：前半段是候选范围，后半段是选择规则。allkeys-lru 会在所有键里做近似 LRU；volatile-lru 只看设置了过期时间的键。后者的前提很硬：业务必须可靠地给可淘汰数据设置 TTL。

纯缓存实例：先从 allkeys-lru 或 allkeys-lfu 比较

如果实例里的键都只是可重建缓存，且没有“永远不能丢”的数据，allkeys-lru 是容易解释的起点：较久没访问的键更可能被淘汰。访问频率长期很不均匀、热点键需要稳定留存时，再用压测和线上指标比较 allkeys-lfu。

混合实例：volatile 只能保护没有 TTL 的键

volatile-lru、volatile-lfu 和 volatile-ttl 都只从带过期时间的键中选择。没有 TTL 的配置、锁或状态键不会因为它们出现在同一个实例里就自动变成候选。候选集合耗尽后，写入仍会失败，所以混合实例更需要拆分数据或显式管理 TTL。

这里别急着用 volatile-ttl。它偏向淘汰剩余 TTL 更短的键，适合过期时间本身就是业务优先级的场景；如果 TTL 只是“最终清理”，它未必等价于最近最少使用。

从旧策略切换时，怎样避免把故障放大

调整前先记录当前策略、内存水位、命中率和错误率，保留一个可回退的配置快照。变更可以先在低流量实例或压测环境验证，再把影响范围缩小到一个实例。

CONFIG SET maxmemory-policy allkeys-lru
INFO stats

如果业务对“写入必须成功”有硬要求，noeviction 反而更诚实，但调用方必须处理内存不足错误，不能把 Redis 当无限存储。若这是可重建缓存，允许淘汰通常比让所有新写入失败更符合目标。

回归检查：命中率、淘汰量和错误要一起看

策略切换后，至少观察一个完整业务高峰。命中率下降、evicted_keys 激增和后端回源压力上升，可能说明缓存容量不足，也可能说明淘汰规则与访问模式不匹配。单看内存保持在上限附近并不能证明结果健康。

INFO stats
INFO memory
CONFIG GET maxmemory-policy

几个容易误判的结果

• evicted_keys=0 不一定是好消息，也可能是策略为 noeviction 或没有触顶。
• 命中率短时升高不代表长期稳定，热点切换后要看回源延迟和数据库压力。
• volatile-* 下写入失败时，优先检查键是否真的设置了过期时间，而不是继续调大淘汰力度。

迁移清单：把策略选择写成可回退的验收项

最后留下四项记录：变更前后的 maxmemory-policy、高峰期命中率、evicted_keys 增量，以及应用侧内存不足或回源错误。若业务错误增加而回源也没有改善，先恢复原策略并检查容量、TTL 覆盖率和实例混用情况。

相关问题

Redis 的 LRU 是精确按最后访问时间排序吗？

不是。Redis 使用近似 LRU 采样来降低维护成本，样本数量和版本配置会影响结果，验收时应看整体命中率而不是某个键的去留。

设置了 TTL 就一定适合 volatile-lru 吗？

不一定。要先确认绝大多数可淘汰键都有 TTL，并确认没有 TTL 的键不能被误当成候选；否则 allkeys 策略或拆分实例可能更清楚。

小结

选择 Redis 内存淘汰策略，先划定候选范围，再决定按近期访问、访问频率还是剩余 TTL 选键。变更后把命中率、淘汰计数、内存水位和业务错误放在同一张观察表里，才能知道这是一次有效的容量治理，还是把内存问题换成了回源问题。