Redis 的内存淘汰策略有哪些，什么时候触发？

核心回答

Redis 内存淘汰是在配置了 maxmemory 上限，且用于淘汰判断的内存超过这个上限时，按 maxmemory-policy 尝试移除键，为后续操作腾出空间。没有可淘汰的键，或选择不淘汰策略时，相应写入命令可能返回 OOM 错误。

它与过期删除是两回事：过期删除处理已经到达 TTL 的键；内存淘汰处理容量压力，可能删除尚未过期、甚至没有 TTL 的键，取决于策略。

常见的 8 种策略可以按“候选范围”和“选择方法”记忆：

• allkeys-lru、allkeys-lfu、allkeys-random：从所有键中，分别按最近最少使用、较低访问频率、随机方式选择。
• volatile-lru、volatile-lfu、volatile-random：使用同样的选择方法，但候选范围仅限设置了 TTL 的键。
• volatile-ttl：从设置了 TTL 的键中，优先选择剩余存活时间较短的候选键，不要求它已经过期。
• noeviction：不因内存压力主动淘汰键；超限且无法满足相应命令的内存要求时拒绝该类写入，普通读取、删除等仍可执行。它是 Redis Open Source 的默认策略。

版本要补充：Redis 8.6 新增 allkeys-lrm 和 volatile-lrm，因此 8.6 的配置支持 10 种。 LRM 是最近最少修改，只用写操作更新相应时间，不会因为键被频繁读取就把它视为“刚修改过”。

进一步解释

什么时候触发，maxmemory 是不是进程内存硬上限？

以 Redis Open Source 8.6.0 为例，正常命令处理路径会检查内存并尝试淘汰，不能简单理解成“只有新增写入执行完才检查”。一次命令分配较多内存时，也可能暂时超过上限，淘汰工作本身还有执行预算。

maxmemory 的比较口径不是操作系统看到的整个进程 RSS。部分复制、AOF 缓冲不计入淘汰判断，因此机器内存使用量不能只按这个参数估计。把 maxmemory 设为 0 表示不通过它设置数据内存上限，也不代表进程拥有无限内存。

volatile-* 为什么也可能写不进去？

volatile 在这里表示候选键具有过期时间，而不是候选键已经过期。如果内存主要被没有 TTL 的键占用，带 TTL 的键又已淘汰完，就没有合适候选了，此时这类策略会表现得像 noeviction，不能继续靠它们释放足够空间。

例如某个缓存键还有一小时才过期，在内存压力下仍可能被 volatile-lru 淘汰；另一个无 TTL 的键则不在该策略的候选范围内。TTL 不保证键一定能保存到那个时刻。

LRU、LFU 和 LRM 怎么选？

LRU 看最近是否使用，LFU 看一段时间内的访问热度，LRM 看最近是否修改。一个键每天被大量读取、但很久不修改，按 LRU/LFU 可能较容易保留，按 LRM 则可能成为淘汰候选。因此 LRM 不是 LRU 的通用升级，应看业务到底希望保留什么。

Redis 的 LRU 并非维护一个全量、严格有序的淘汰链表，而是随机采样并维护候选。LFU 也是近似算法，使用概率计数并随时间衰减，不是永不减少的真实访问总次数。更多采样会增加选择成本，也不等于任何负载下都有更高收益。

常见追问

纯缓存一般选什么？

如果键都可以从权威数据源重建，可以从 allkeys-lru 或 allkeys-lfu 等策略评估，根据命中率、淘汰频率、回源压力和访问模式选择。缓存被淘汰后的回源也要有容量保障。

不能随意丢失的数据，应与可淘汰缓存区分容量和实例边界；即使使用 noeviction，也需要处理容量不足及写入失败。单靠策略名称不能替代业务设计。

设置了 TTL，就不用配置淘汰策略了吗？

TTL 决定键的有效期，不保证到期前总数据量一定放得下。大量未到期的键仍会把内存占满。反过来，配置了淘汰策略，也不能用它替代业务有效期。

键减少了，为什么内存指标没有立即按比例下降？

要区分键被移除、对象内存释放，以及分配器和操作系统呈现的内存。淘汰算法决定删谁，异步释放决定怎样回收对象；RSS 还受分配器保留和碎片等影响。排查时应同时看实际淘汰数量、过期数量及内存构成。

参考资料