Redis默认回收策略到底咋回事，带你一起深挖那些不为人知的细节和极限表现

很多人刚开始用Redis,可能都听过“内存满了Redis会删数据”，但具体怎么删，为啥这么删，里面门道可就多了，今天咱就抛开那些官方手册，直接挖一挖Redis默认回收策略里那些不为人知的细节和它在极限压力下的真实表现。

咱得明确一个核心问题：Redis默认的回收策略到底是什么？ 根据Redis官方文档的明确说明，从很早的版本开始，一直到目前最新的稳定版，默认的回收策略是 noeviction，这个词字面意思就是“不回收”，你没看错，默认情况下，当Redis使用的内存超过了配置文件里 maxmemory 设置的上限时，它会选择“摆烂”——不再接受任何会增加内存使用的写命令（SET, HSET, LPUSH 等），并对这些写命令返回一个错误，而读命令（GET, HGETALL）依然可以正常执行。

那为啥要这么设计？这其实是Redis开发者一种“保守治疗”的哲学，他们认为，与其冒着误删重要数据的风险去自动清理，不如把决定权交给开发者，内存满了，就是一个明确的告警信号，告诉你要么该扩容了，要么该去检查一下是不是有内存泄漏或者不合理的使用方式了，这是一种“宁可拒绝请求，也不丢可能重要的数据”的策略，尤其适合把Redis当作严格的数据存储而非缓存的场景。

如果你把Redis主要当缓存用,希望它在内存满时自动淘汰一些旧数据来腾地方，那 noeviction 显然就不合适了，这时，你就需要主动修改配置，Redis提供了另外几种“积极”的回收策略，主要分两大类：

第一类：带淘汰算法的策略（针对所有key） 这类策略会从整个数据集里挑“软柿子”捏。

• allkeys-lru：这是最常用、也往往是效果最好的缓存策略，LRU是“最近最少使用”的意思，它会尝试淘汰最长时间没被访问过的key，但这里有个非常重要的细节！为了节省内存，Redis实现的是一种近似LRU算法，它并不是给每个key都维护一个精确的访问时间戳，而是通过随机采样一小部分key（默认是5个），然后从这5个里淘汰掉那个最旧的，这样性能开销极小，虽然不一定能淘汰掉绝对最久没用的那个，但在实际应用中准确度已经非常高，你可以通过调整采样数量（maxmemory-samples）来平衡精度和CPU消耗。
• allkeys-lfu：这是Redis 4.0引入的新策略，LFU是“最不经常使用”，它淘汰的是访问频率最低的key，这个策略在处理周期性访问或突发访问流量时，比LRU可能表现更好，因为它更关注访问的频次而非仅仅是最近一次访问的时间。
• allkeys-random：简单粗暴，随机淘汰，这在你对key的访问模式没有明显规律，或者觉得每个key都差不多重要时可以用，性能开销最小，但可能一不小心就把一个热点key给删了。

第二类：带淘汰算法的策略（仅针对设置了过期时间的key） 这类策略的名字以 volatile- 开头，volatile-lru, volatile-lfu, volatile-random，它们的行为和上面第一类的对应策略一模一样，唯一的区别是，它们只会在那些已经设置了过期时间的key里面进行淘汰，而那些没设过期时间的永久key，会被认为是重要数据而受到保护，永远不会被这些策略自动删除，这适合你希望区分核心数据和缓存数据的场景。

在极限表现下会发生什么？

1. 当使用默认的 noeviction 策略时：极限就是写请求被大量报错，如果你的客户端没有良好的错误处理机制，应用服务可能会出现异常，这时候Redis本身的内存使用会稳定在 maxmemory 阈值，但服务可用性会大打折扣，这逼着你必须立刻处理。

2. 当使用各种LRU/LFU淘汰策略时：极限表现就是一场持续不断的“内存战争”，新的数据不断涌入，旧的数据不断被踢出去，这时候，淘汰的精准度就成了关键，如果你的采样数（maxmemory-samples）设置得太低，或者访问模式非常复杂，近似LRU/LFU可能会误伤一些其实还有用的数据，导致缓存命中率急剧下降，你会观察到Redis的CPU开销因为持续的淘汰计算而上升，同时由于频繁删除key，持久化（AOF）的日志里也会充满 DEL 命令。

3. 一个隐藏的细节：内存超售：即使你设置了 maxmemory，Redis实际使用的内存有可能短暂地略微超过这个限制，这是因为Redis可能在同一个命令中处理多个key（比如一个大的集合操作），或者在淘汰旧key之前需要先写入新key的内容，它会在命令执行后尽快回收以达到平衡，但在那个瞬间，内存使用是超出的，这对于监控来说需要留意。

选择哪种回收策略,根本不是拍脑袋决定的，它完全取决于你的业务场景：Redis对你而言是可靠存储还是临时缓存？你的数据是否有明显的冷热区分？你的应用是否能容忍因淘汰策略不精准而导致的缓存命中率波动？理解了这些细节，你才能真正驾驭Redis的内存管理，而不是等线上出了故障才手忙脚乱。