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

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

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

先把 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 让某批缓存永远留在候选集之外。代价是它不理解业务优先级：一个“不能丢”的键如果混在同一个实例里，也可能被淘汰。

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 三处确认前提。

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

切换后至少观察一段真实流量：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。

常见问题

volatile-ttl 没有设置 TTL 的键会怎样？

它们不会成为该策略的淘汰候选。若带 TTL 的键不足以释放空间，新增写入可能因达到内存上限而失败。

allkeys-lru 会精确删除最久没访问的键吗？

不会。Redis 使用近似 LRU 以控制额外开销，结果接近但不等同于维护全量访问排序。

可以在同一个实例里混用两种策略吗？

不能对不同键分别配置这两个全局策略。需要不同淘汰规则时，优先拆分实例或重新设计数据生命周期。

只要设置了 TTL，就一定应该用 volatile-ttl 吗？

不一定。若 TTL 只是兜底过期时间，而热点访问才是主要价值信号，allkeys-lru 可能更符合缓存命中目标。