Redis缓存过期淘汰策略使用详解
来源：互联网 2026-07-10 08:40:17在生产环境中使用Redis时，内存配置、过期键清理和缓存淘汰策略是开发者绕不开的核心问题。下面围绕几个常见疑问展开：Redis内存应该设置多大？如何查看和修改内存配置？内存满了之后会发生什么？定期删除和惰性删除该如何选择？缓存淘汰策略又该如何挑选？ 生产上Redis内存需要设置多少才合适 如何配置、
在生产环境中使用Redis时，内存配置、过期键清理和缓存淘汰策略是开发者绕不开的核心问题。下面围绕几个常见疑问展开：Redis内存应该设置多大？如何查看和修改内存配置？内存满了之后会发生什么？定期删除和惰性删除该如何选择？缓存淘汰策略又该如何挑选？
- 生产上Redis内存需要设置多少才合适
- 如何配置、修改Redis的内存大小，具体怎么操作
- 如果内存满了Redis怎么办
- Redis清理内存的方式选择哪种：定期删除和惰性删除
- 怎么选择Redis缓存淘汰策略
这些问题几乎是每个Redis使用者都会遇到的坎。下面从内存设置说起。
长期稳定更新的攒劲资源： >>>点此立即查看<<<
1. Redis内存设置详解
1.1 查看Redis内存
- 配置文件查看Redis最大占用内存
maxmemory
打开Redis配置文件，找到maxmemory参数，注意单位是字节，需要换算一下。
- 通过命令查看默认的内存大小
127.0.0.1:6379>config get maxmemory
返回结果常常是0。这时候你会不会好奇：默认内存是0，那之前的数据怎么存进去的？
1.2 Redis默认内存限制
如果不设置maxmemory，或者把它设为0，在64位操作系统下，Redis不限制内存使用；在32位操作系统下，最多只能用到3GB。注意，64位系统下0就是“不限制”，但生产上可不能这样放任。
一般生产上你如何配置
业界推荐的做法是：将Redis内存设置为物理内存的3/4左右。比如服务器有16GB内存，预留4GB给系统和其它进程，Redis用12GB比较稳妥。当然还要结合具体业务场景和数据量来调整。
1.3 修改Redis内存设置
- 通过修改文件配置
maxmemory 1056236
- 通过命令修改（重启后会失效）
127.0.0.1:6379>config set maxmemory 104856986
查看Redis内存使用命令
127.0.0.1:6379>info memory127.0.0.1:6379>config get maxmemory
设置了maxmemory后，一旦数据量达到上限，如果还有键没有过期时间，写入就会报错。所以必须搭配内存淘汰策略来用。
2. Redis过期键删除策略
一个键过期了，是不是到期立刻就被删除了？答案是否定的。那到底什么时候删？怎么删？Redis提供了三种删除策略。
2.1 立即删除或定时删除
立即删除保证过期键在到期后马上被清理，内存释放最及时。但代价是对CPU极不友好——如果正好赶上CPU在做计算密集型操作（比如交集、排序），删键操作会额外抢占时间片，相当于让CPU一边忙业务一边不停地打扫卫生。总结起来就是：用处理器性能换存储空间，拿时间换空间。
2.2 惰性删除
过期了？先不管。等下次有人访问这个键时，如果发现已经过期，就顺手删掉，并返回不存在。这种方式对内存极其不友好——过期键可能一直赖在内存里，永远没人访问，它们就像内存泄漏一样占着茅坑不拉屎。除非手动执行FLUSHDB，否则这些垃圾数据会堆积起来。总结：用存储空间换处理器性能，拿空间换时间。如果要启用惰性删除的淘汰模式，可以设置lazyfree-lazy-eviction=yes。
2.3 定期删除策略
定期删除是前两种的折中方案：每隔一段时间执行一次删除操作，通过限制执行时长和频率来减少对CPU的影响。Redis默认每100毫秒检查一次，但注意——它不是把全部key都翻一遍，而是随机抽查。如果每隔100ms把所有key扫一遍，Redis早就进ICU了。具体做法是周期性轮询，采用随机抽取的策略，再根据过期键占比动态调整删除频度。
特点1：CPU压力有峰值，但检测频度可以自定义。
特点2：内存压力不算大，长期未被访问的冷数据会被逐步清理。
难点：定期删除的执行频率和时长需要精心调优。太频繁或时间太长，就退化成定时删除，CPU扛不住；太稀疏或时间太短，又和惰性删除一样造成内存浪费。
到这里，你可能已经发现问题了——定期删除时，有的key可能老被抽查到，但有的key可能永远抽不到；惰性删除时，那些过期却没人访问的键也一直活着。大量过期键堆积在内存里，Redis内存空间迟早被撑爆。
3. Redis缓存淘汰策略
3.1 Redis缓存淘汰配置文件
在Redis配置文件（redis.conf）的MEMORY MANAGEMENT部分，可以找到相关设置。
3.2 LRU和LFU算法的区别
简单说一下这两个容易混淆的概念：
LRU（Least Recently Used）：淘汰最长时间未被使用的页面，看的是页面最后一次被访问的时间，优先淘汰那个最久没被碰过的。
LFU（Least Frequently Used）：淘汰一定时期内被访问次数最少的页面，看的是频次。例如，十分钟内页面2被访问了5次，页面3只被访问了1次，那么LFU会淘汰页面3，而LRU则可能淘汰页面1（假如页面1是十分钟前被访问的，更久远）。
两者的核心区别：LRU看“最后一次访问距现在多久”，LFU看“一段时间内被访问了多少次”。
3.3 淘汰策略有哪些（R7版本）
- noeviction：不驱逐任何键。内存满了，写入操作直接报错，数据不会被删。
- allkeys-lru：对所有key使用LRU算法，优先淘汰最近最少用的。
- volatile-lru：只对设置了过期时间的key使用LRU算法。
- allkeys-random：随机淘汰所有键。
- volatile-random：随机淘汰设置了过期时间的键。
- volatile-ttl：淘汰马上要过期的键（TTL最小的）。
- allkeys-lfu：对所有key使用LFU算法。
- volatile-lfu：对设置了过期时间的key使用LFU算法。
总结一下就是：2个维度（过期键筛选 vs. 全键筛选），4种算法（LRU、LFU、random、ttl），组合起来正好8个选项。
4. 淘汰策略选择建议
如果你的数据访问模式是典型的热点数据（少量key被频繁访问），推荐allkeys-lru，因为它能有效保留热门数据。如果所有key被访问的概率差不多，可以选择allkeys-random。如果你对每个key的过期时间把握得很准，可以考虑volatile-ttl。
下面是一些具体场景下的建议：
- allkeys-lru：最通用，适用于绝大多数缓存场景。
- volatile-lru：数据有存活时间，且希望保留其中热门数据。
- allkeys-random：数据访问无规律，或频率差异不大。
- volatile-random：淘汰过期数据，但不想机械依赖LRU。
- volatile-ttl：适合会话缓存这类即将失效的数据。
- allkeys-lfu / volatile-lfu：适合有短时高频访问（如秒杀场景）的业务。
- noeviction：默认策略，适合不允许丢失任何数据的场景（比如一些关键业务），但可能会阻塞写入。
选择淘汰策略时，还要考虑以下几点：
- 数据重要性：关键业务数据宜选择保守策略（如noeviction），并搭配持久化。
- 内存资源：如果内存充裕，可以放宽淘汰。
- 性能影响：某些策略在内存紧张时可能产生额外抖动。
- 数据访问模式变化：定期评估，必要时调整策略。
5. 配置淘汰策略
在redis.conf中用maxmemory-policy指令指定。例如：
maxmemory-policy allkeys-lru
启动时也可以通过命令行指定：
redis-server --maxmemory-policy allkeys-lru
运行时动态修改（重启后失效）：
CONFIG SET maxmemory-policy allkeys-lru
6. Redis缓存淘汰策略配置性能建议
光设一个策略还不够，下面这些优化点值得关注：
- 选对策略：根据访问模式选合适的，别盲目跟风。
- 设好内存上限：
maxmemory不要超过物理内存，避免触发OS swap。 - 调整采样数量：
maxmemory-samples控制LRU/LFU采样精度，数值越大精度越高，CPU开销也越大。 - 监控内存：定期用
INFO memory查看内存使用情况，评估策略效果。 - 合理设过期时间：给不同键设置合适的TTL，让过期键自动释放。
- 持久化兜底：重要数据通过RDB或AOF持久化，即使被淘汰也可以恢复。
- 避免大键：大键操作耗时，尽量拆成小对象。
- 检查持久化策略：非必须场景可关闭持久化以提升性能。
- 分布式架构：数据量大时使用Redis集群分片，突破单机内存瓶颈。
7. 总结
从内存配置到过期键删除，再到淘汰策略的选择，每一步都影响Redis的稳定性和性能。生产环境中没有银弹，结合业务特点做合理配置才是正道。希望这篇梳理能帮你避开一些常见的坑。