Redis maxmemory-policy 选错会怎样：volatile-lru、allkeys-lfu 与写入失败边界

Redis 的 maxmemory 到线后会不会自动删键，答案取决于 maxmemory-policy，而不是“Redis 默认会帮你清理”。如果缓存键都允许重建，通常从 allkeys-lru 或 allkeys-lfu 开始评估；如果同一个实例还放着不能丢的业务键，volatile-lru 只适合在过期键集合足够完整时使用，否则写入仍可能失败。noeviction 则明确拒绝新增数据，把保护数据完整性的责任交回应用。

先把键分成“丢了能重建”和“丢了就是业务数据”两类，再选 allkeys、volatile 或 noeviction；选完还要用 evicted_keys、keyspace_hits、keyspace_misses 和 rejected 命令核对结果。

先判断：这个 Redis 实例里的键能不能丢

有一次缓存命中率突然下降，第一反应往往是把策略改成 allkeys-lru。这个动作有一个前提：Redis 里的每个键都只是数据库副本，删掉后可以重新加载。如果同一实例里还有会话、幂等记录或任务状态，淘汰策略就不只是性能参数，而是数据边界。

可以先按下面的两个问题分流：

• 全部都是可重建缓存：在 allkeys-lru 与 allkeys-lfu 之间按访问特征选择。
• 缓存与不能丢的数据混放：优先拆实例；暂时不能拆时，才考虑 volatile-*，并确认需要保护的键没有 TTL。
• 宁可让上游感知容量不足，也不接受自动删除：使用 noeviction，并为 OOM 错误准备降级路径。

这三个节点——可重建缓存、volatile-*、noeviction——决定了后面每一条配置建议，图中也只保留这条真实判断链。

allkeys-lru 和 allkeys-lfu，差别在访问模型

allkeys-lru 会在所有键中近似淘汰最近最少使用的键；allkeys-lfu 则根据访问频率做近似淘汰。商品详情、配置快照这类热点明显、读多写少的缓存，先用 allkeys-lru 往往容易解释；热点长期稳定、冷数据访问很少时，可以压测 allkeys-lfu。

两者都不是精确排序。Redis 会采样候选键来完成淘汰，不能把“LFU 保证最冷的键先删”当成严格承诺。切换策略前，保留一段可比较的指标窗口，避免刚好遇到流量形态变化。

# 只在测试实例或已审批的运行变更中执行
CONFIG SET maxmemory 100mb
CONFIG SET maxmemory-policy allkeys-lru
INFO stats
INFO memory

运行时 CONFIG SET 不会替你修改 redis.conf。确认结果后要把配置写入部署文件，或按变更流程使用 CONFIG REWRITE，否则重启会回到旧值。

volatile-lru 不是“保护永久键”的万能开关

volatile-lru 只会在带过期时间的键中寻找淘汰对象。假设缓存键有 TTL，而会话键没有 TTL，这个策略确实能避开会话键；但如果所有键都没有 TTL，或者带 TTL 的键已经没有合适候选，行为会接近 noeviction，新增写入仍可能返回 OOM。

因此不要只看配置名判断安全性。上线前抽样检查关键前缀的 TTL，确认“允许被删”的集合真实存在，再做小流量压测。

TTL cache:product:42
TTL session:user:7
CONFIG GET maxmemory-policy

如果 cache:product:42 返回正数、而 session:user:7 返回 -1，这只是说明两个键的过期设置不同，并不代表整个实例已经具备足够的淘汰候选。

用 INFO 把“策略合适”变成可验证结论

改完策略不能只看 Redis 进程还活着。用 INFO stats 观察 evicted_keys、keyspace_hits 和 keyspace_misses，用 INFO memory 看 used_memory_dataset 与 mem_not_counted_for_evict。如果命中率变差且 evicted_keys 快速增长，可能是错误的键被持续淘汰；如果使用 noeviction 或 volatile-*，还要留意被拒绝的写命令。

INFO stats
INFO memory
CONFIG GET maxmemory
CONFIG GET maxmemory-policy

判断顺序是：先确认 maxmemory-policy 与变更记录一致，再看数据集是否超过上限，最后把淘汰、命中/未命中和写入拒绝放在同一时间窗口里比较。这样才能区分“缓存本来就冷”与“策略淘汰错了键”。

三个容易踩中的边界

复制和 AOF 会占用未计入淘汰判断的缓冲区

Redis 官方文档提醒，复制缓冲区和 AOF 缓冲区的内存不计入触发淘汰的比较值。主从或持久化实例不要把 maxmemory 顶到机器物理内存，应该给这些缓冲区留下余量，并结合 mem_not_counted_for_evict 观察。

一次大写入可能暂时超过 maxmemory

例如把一个很大的集合交集结果写入新键，单条命令可能让内存短时越过上限。不能只用“最终回到上限以下”来推断这条命令的峰值风险，应该把大对象写入纳入压测。

动态配置不等于部署配置

CONFIG SET 改的是运行中的实例。若只在命令行改完而没有更新 redis.conf 或执行配置重写，下一次重启可能恢复旧策略。生产变更要把命令结果、配置文件和回滚值一起留档。

相关问题

什么时候优先 allkeys-lru？

当所有键都可重建，并且访问热点明显、近期访问比历史访问更能代表未来命中时，优先从 allkeys-lru 做基线测试。

volatile-lru 为什么会像 noeviction？

因为它只能从带过期时间的键中挑选；没有可淘汰的过期键时，新增数据没有候选对象，写入就可能被拒绝。

策略变更后最少看哪些指标？

至少同时记录 evicted_keys、keyspace_hits、keyspace_misses、used_memory_dataset 和 mem_not_counted_for_evict，并单独记录写命令的错误率。

最后的选择清单

1. 能否接受任意键被删除？能则比较 allkeys-lru 与 allkeys-lfu。
2. 不能任意删除但缓存键都有可靠 TTL？才评估 volatile-lru、volatile-lfu 或 volatile-ttl。
3. 不能删除且必须保留写入失败信号？选择 noeviction，并让应用处理 OOM。
4. 复制或 AOF 是否开启？给缓冲区和大写入峰值留余量。
5. 是否完成指标对比和重启后的配置复核？没有就不要把变更当成完成。