内存淘汰不直接触发RDB/AOF写盘，仅决定删除哪个key；但高频淘汰会间接拖慢持久化性能，影响fork时间、AOF rewrite负载及内存碎片整理效率。

内存淘汰本身不直接触发RDB/AOF写盘

Redis 的内存淘汰（maxmemory-policy）只决定“该删哪个 key”，不涉及磁盘 I/O。它发生在内存不足时的写入路径上，纯粹是内存管理行为。RDB 和 AOF 的触发完全独立：RDB 由 save 配置、BGSAVE 命令或主从同步触发；AOF 刷盘由 appendfsync 控制。淘汰策略不会让 Redis “多写一次磁盘”。

但高频淘汰会间接拖慢持久化性能

频繁触发淘汰意味着内存长期逼近 maxmemory 上限，这会带来两个隐性开销：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• allkeys-lru 或 volatile-lru 等策略需维护访问时间戳，增加每次键操作的 CPU 开销；大量淘汰时，这部分开销叠加，可能延长 BGSAVE fork 子进程的准备时间（fork 依赖当前内存页状态）
• 淘汰过程本身会修改键空间（删除 key），导致 RDB 快照或 AOF rewrite 时需要处理更多“中间态”——例如刚被淘汰又新写入的键，在 AOF rewrite 中可能被重复压缩或遗漏，增大 rewrite 负载
• 若使用 allkeys-random 等低开销策略，虽减少 CPU 压力，但因误删热点数据，可能引发应用层重刷缓存，反而加剧写入和淘汰循环，形成恶性反馈

RDB fork 延迟与淘汰策略的耦合点

这是最容易被忽略的实际瓶颈：

• latest_fork_usec（通过 INFO stats 查看）若持续 >500ms，说明 fork 成本高；此时若同时启用 allkeys-lru，LRU 更新会加剧内存页脏页率，进一步拉长 fork 时间
• noeviction 虽不淘汰，但写入失败后应用重试或降级逻辑可能造成更乱的内存分布，间接影响后续 fork 效率
• 真正安全的组合是：maxmemory 留出 15%~20% 余量 + allkeys-lru + 关闭 activedefrag（除非明确需要）——避免碎片整理与淘汰双重 CPU 压力

AOF rewrite 期间淘汰行为需特别注意

BGREWRITEAOF 过程中，Redis 仍接收写命令并追加到新 AOF 文件。此时若发生内存淘汰：

• 被淘汰的 key 对应的写命令仍会进入 AOF，但该 key 已不存在——AOF 文件里留下“无效操作”，后续加载时虽无害，但浪费磁盘空间和解析时间
• 如果淘汰策略是 volatile-ttl，而大量 key TTL 集中到期，可能在 rewrite 窗口内集中触发删除，导致 AOF 缓冲区（aof_buf）瞬时膨胀，增大 sync 延迟风险
• 建议在业务低峰期执行 BGREWRITEAOF，并确保 auto-aof-rewrite-percentage 不设过低（如低于 100），避免 rewrite 过于频繁

实际调优时，别只盯着 maxmemory-policy 单独改；要连同 maxmemory 设置、INFO memory 中的 mem_fragmentation_ratio、以及 INFO stats 的 evicted_keys 和 latest_fork_usec 一起看——三者不匹配，光换策略没用。