Redis数据淘汰策略详解：从原理到实践

Redis数据淘汰策略详解：从原理到实践

在使用Redis的过程中，你是否遇到过这样的情况：明明配置了最大内存限制，却突然收到“OOM command not allowed when used memory > ‘maxmemory’”的错误？这很可能是Redis数据淘汰策略没有正确配置导致的。作为高性能的内存数据库，Redis的内存管理至关重要，而数据淘汰策略正是内存管理的核心机制之一。本文将从原理、分类、配置到实践建议，全面解读Redis的数据淘汰策略。

一、为什么需要数据淘汰策略？

Redis是基于内存的数据库，而内存资源是有限的。当我们通过maxmemory配置（单位：字节）设定了Redis的最大可用内存后，随着数据不断写入，总有一天会达到这个内存上限。此时如果再有新数据写入，Redis就必须决定：是拒绝写入请求，还是删除部分旧数据腾出空间。

数据淘汰策略（Maxmemory Policy）就是用来解决这个问题的规则——它定义了Redis在内存满时，应该优先删除哪些数据，以保证新数据能正常写入。

如果未配置淘汰策略（或策略为noeviction），当内存满时Redis会拒绝所有写操作（读操作不受影响），这也是开头提到的OOM错误的常见原因。

二、Redis数据淘汰策略的分类

Redis的淘汰策略可以按照“淘汰范围”和“淘汰规则”分为两大类，目前（Redis 6.2及以上版本）共有8种策略，我们逐一解析。

（一）按“淘汰范围”划分：是否限制淘汰数据的类型

（二）8种核心淘汰策略及原理

根据官方文档，8种策略的作用和适用场景如下：

关键概念补充：LRU和LFU的区别

上面提到的LRU和LFU是两种经典的缓存淘汰算法，容易混淆，这里重点区分：

• LRU（Least Recently Used）：最近最少被访问
  基于“访问时间”判断：如果一个数据很久没被访问，就认为它未来被访问的概率低，优先淘汰。
  举例：A键1小时前被访问，B键10分钟前被访问，则LRU会淘汰A键。

• LFU（Least Frequently Used）：最近最少被使用
  基于“访问频率”判断：如果一个数据在最近一段时间内被访问的次数少，就认为它未来被访问的概率低，优先淘汰。
  举例：A键1小时内被访问1次，B键1小时内被访问10次，则LFU会淘汰A键。

两者的核心差异：LRU关注“时效性”（是否最近被访问），LFU关注“热度”（访问频率）。例如，一个数据半年前被频繁访问（高频率），但最近1个月没被访问（非最近），LRU会淘汰它，而LFU可能保留它。

三、如何配置和查看淘汰策略？

（一）配置方法

（二）查看当前策略

使用config get命令查看当前配置：

# 查看最大内存和淘汰策略
127.0.0.1:6379> config get maxmemory
1) "maxmemory"
2) "1073741824"

127.0.0.1:6379> config get maxmemory-policy
1) "maxmemory-policy"
2) "allkeys-lru"

四、淘汰策略的底层实现：近似算法的取舍

你可能会有疑问：LRU需要记录每个键的访问时间，当数据量很大时（如百万级键），计算“最近最少访问”会不会很耗时？

实际上，Redis的LRU和LFU并非“严格精确”的实现，而是近似算法——通过随机采样（默认采样5个键，可通过maxmemory-samples配置），从采样结果中选择最符合淘汰规则的键。

这样做的原因是平衡性能和精度：严格的LRU需要维护有序链表，每次访问都要调整位置，会消耗大量CPU；而近似算法通过少量采样就能达到接近的效果，且性能损耗极低。

如果对精度有更高要求，可以通过config set maxmemory-samples 10提高采样数量（取值范围3-10），但需注意：采样数越多，CPU消耗越大。

五、实践建议：如何选择适合的淘汰策略？

选择淘汰策略的核心原则是：让Redis保留“最有价值”的数据，而“价值”由业务场景决定。以下是常见场景的选择建议：

1. 缓存场景（最常用）

缓存的核心需求是“保留热点数据，淘汰冷数据”，推荐优先使用：

• allkeys-lru：如果所有数据的访问频率差异明显（如商品详情缓存，热门商品访问频繁），LRU能有效保留最近访问的热点数据。
• allkeys-lfu：如果数据访问有“长期频率”特征（如用户偏好设置，高频访问的偏好长期稳定），LFU比LRU更适合（避免偶尔访问的冷数据被保留）。

2. 有过期时间的业务（如验证码、临时令牌）

这类场景中，数据本身有过期时间，淘汰应优先考虑过期相关规则：

• volatile-ttl：如果希望“即将过期的数据优先被淘汰”（如10分钟后过期的验证码，优先淘汰剩余1分钟的，保留剩余5分钟的），选此策略。
• volatile-lru：如果过期数据中也有访问频率差异（如临时令牌，活跃用户的令牌被频繁验证），希望保留常访问的过期数据（未真正过期前），选此策略。

3. 不允许数据丢失的场景（如配置存储、计数器）

如果数据一旦丢失会影响业务（如系统核心配置、不可重建的计数器），应选择：

• noeviction：拒绝新写操作，强制业务层处理内存满的问题（如扩容、清理无效数据），避免数据被误删。

4. 数据访问均匀，无明显热点（如日志缓存）

如果所有数据的访问频率接近（如用户操作日志，每条日志被访问的概率相同），随机淘汰更高效：

• allkeys-random 或 volatile-random（根据是否有过期时间选择）。

额外提醒：配合过期时间设置效果更佳

即使选择了allkeys-lru这类全局策略，为数据设置合理的过期时间（expire命令）仍然很重要：

• 避免“僵尸数据”长期占用内存（如已下架的商品缓存，即使被访问过，也应在过期后被淘汰）。
• 减轻淘汰策略的压力（过期数据会被主动清理，减少LRU/LFU的计算量）。

六、常见问题解答

1. 配置了allkeys-lru，为什么有些刚访问的数据被淘汰了？

可能原因：

• 内存已满时，新数据写入触发淘汰，即使数据刚被访问，但如果是采样中“最不常访问”的（相对其他采样数据），仍可能被淘汰。
• 数据未被正确“标记”为访问：Redis的LRU基于“最后一次访问时间”，如果访问是通过get等命令，会更新时间；但如果是exists、ttl等命令，默认不更新（可通过touch命令手动更新访问时间）。

2. 内存没到maxmemory，为什么数据也会被淘汰？

两种可能：

• 数据设置了过期时间，Redis会定期清理过期键（主动淘汰），与内存是否满无关。
• 内存碎片：Redis使用内存分配器（如jemalloc），可能存在内存碎片（已释放但未被复用的内存），实际使用内存未到maxmemory，但可用内存不足，触发淘汰。可通过info memory查看mem_fragmentation_ratio（内存碎片率），大于1.5时建议优化。

3. 如何监控淘汰策略的效果？

通过info stats命令查看相关指标：

• evicted_keys：被淘汰策略删除的键数量（数值增长说明策略在生效）。
• keyspace_hits/keyspace_misses：缓存命中/未命中次数（命中率下降可能说明策略不合适）。

七、总结

Redis的数据淘汰策略是内存管理的核心，它决定了内存满时数据的“生存规则”。选择策略时，需结合业务场景的“数据价值”判断：

• 缓存场景优先allkeys-lru或allkeys-lfu；
• 有过期时间的场景考虑volatile-ttl或volatile-lru；
• 不允许丢失数据选noeviction；
• 访问均匀选随机策略。

同时，合理配置maxmemory、采样数，配合过期时间设置，并通过监控指标持续优化，才能让淘汰策略真正发挥作用，保证Redis的高性能和稳定性。

希望本文能帮你理清Redis淘汰策略的逻辑，在实际业务中少走弯路。如果有其他疑问，欢迎在评论区交流！