当前位置：首页 > 文章列表 > 数据库 > Redis > Redis maxmemory-policy 选 allkeys-lru 还是 volatile-ttl

Redis maxmemory-policy 选 allkeys-lru 还是 volatile-ttl

来源：17golang原创 2026-09-11 12:54:34 0浏览收藏

Redis 到达 `maxmemory` 后，`allkeys-lru` 和 `volatile-ttl` 的核心区别是“候选键范围”与“淘汰依据”：前者可以从所有键里找较久未访问的键，后者只看设置了过期时间的键，并优先清理剩余 TTL 更短的键。纯缓存、没有统一 TTL 或热点访问明显时，通常先选 `allkeys-lru`；只有业务已经把 TTL 当作淘汰提示，并且能保证候选键都带 TTL 时，`volatile-ttl` 才更合适。

官方地址：https://redis.io/

要点速览

allkeys-lru 不要求键有 TTL，适合整体作为缓存的实例。
volatile-ttl 只处理带过期时间的键，没有可用 TTL 键时不能覆盖全库。
不要只看内存占用，结合 evicted_keys、expired_keys 和写入拒绝判断策略是否合适。

先把 maxmemory 和数据边界分清楚

maxmemory 是 Redis 数据达到的内存上限，策略在写入导致内存超过上限时决定哪些键可以被清理。先问一个比“LRU 还是 TTL”更重要的问题：这个实例里的每个键是否都是可重新生成的缓存？如果答案是肯定的，淘汰通常只是缓存未命中；如果同一实例还保存用户配置、幂等记录或业务状态，就不能用一个全局淘汰策略替代数据分层。

需要保留的持久数据与缓存最好拆到不同实例或不同职责的存储中。若确实混用，volatile-ttl 至少把淘汰范围限定在有过期时间的键，但这不是数据安全保证：一旦持久键也被错误设置 TTL，仍然可能被选中。

allkeys-lru：不依赖 TTL 的整体缓存方案

allkeys-lru 在所有键中使用近似 LRU，倾向保留近期访问过的热点键。它适合商品详情、配置快照、接口响应这类“值丢了可以回源”的缓存，也适合应用没有给每个键设置 TTL、但访问呈明显冷热分布的场景。Redis 使用近似算法而不是维护精确 LRU，以减少额外开销；因此它不是严格按全量访问时间排序的队列。

# 先在运行中的实例试用，确认这是可丢失的缓存
redis-cli CONFIG SET maxmemory 2gb
# 所有键都可作为淘汰候选，按近似 LRU 保留热点
redis-cli CONFIG SET maxmemory-policy allkeys-lru
# 查看当前策略，避免只修改了配置文件却未作用于当前进程
redis-cli CONFIG GET maxmemory maxmemory-policy

这类策略的优点是规则简单、不会因为漏写 EXPIRE 让某批缓存永远留在候选集之外。代价是它不理解业务优先级：一个“不能丢”的键如果混在同一个实例里，也可能被淘汰。

Redis allkeys-lru 与 volatile-ttl 的候选键范围和 maxmemory 边界关系图 — 图1：allkeys-lru 可以从全体键中选择，而 volatile-ttl 先受限于带过期时间的候选集合。

volatile-ttl：把 TTL 当作淘汰提示

volatile-ttl 只在带过期时间的键中选择，剩余 TTL 越短，越优先成为淘汰候选。它适合缓存层已经明确设置不同 TTL 的场景，例如临时推荐结果只保留几十秒，较稳定的字典缓存保留更久。这里的 TTL 不只是“多久后自动过期”，还变成了内存压力下的优先级提示。

# 只有设置过期时间的键才进入 volatile-ttl 候选集
redis-cli SET product:hot "..." EX 300
# 临时结果设置更短 TTL，内存紧张时更容易先被淘汰
redis-cli SET search:temporary "..." EX 30
# 选择按剩余 TTL 处理带过期时间的键
redis-cli CONFIG SET maxmemory-policy volatile-ttl

最常见的误区是以为“给部分键设置 TTL 就够了”。如果写入流程有分支漏掉过期时间，未设置 TTL 的键不会进入这个策略的候选范围；当可淘汰键不足时，写入可能报内存上限错误。因此，启用它前要从 INFO keyspace、应用写入代码和抽样键的 TTL 三处确认前提。

用这张表完成选择并验证结果

场景	优先策略	原因	主要风险
纯缓存、TTL 不统一或经常漏写	`allkeys-lru`	全库都能成为候选，热点更容易留下	误把不可丢数据放入同一实例
所有缓存键都有 TTL，TTL 代表业务优先级	`volatile-ttl`	短 TTL 键先让出空间	无 TTL 键不会被淘汰
写入后不能丢任何数据	重新评估容量或 `noeviction`	淘汰策略不应替代持久化设计	达到上限后写入失败

切换后至少观察一段真实流量：INFO stats 中的 evicted_keys 表示被淘汰数量，expired_keys 表示自然过期数量；如果淘汰很多但命中率下降，可能是内存太小或策略不匹配。如果使用 volatile-ttl 时写入频繁失败，先检查候选键是否真的带 TTL，而不是立刻把容量上限调高。

# 观察淘汰与过期趋势；输出只读，不会改变策略
redis-cli INFO stats | grep -E 'evicted_keys|expired_keys'
# 抽查一个业务键的剩余时间，-1 表示没有过期时间
redis-cli TTL product:hot

运行时 CONFIG SET 只影响当前实例，重启后还要把配置同步到 redis.conf，或在确认变更后执行 CONFIG REWRITE。最终建议是：纯缓存默认从 allkeys-lru 评估；只有 TTL 完整、TTL 有业务含义且能持续监控时，才选择 volatile-ttl。