Redis禁止BGREWRITEAOF与BGSAVE同时运行，是为避免fork、内存拷贝、序列化及磁盘写入叠加引发I/O与CPU过载，防止延迟激增或OOM崩溃；二者互斥，INFO中rdb_bgsave_in_progress与aof_rewrite_in_progress不会同时为1。

Redis为什么禁止AOF重写与BGSAVE同时执行

不是Redis“做不到”并发，而是它主动拒绝——BGREWRITEAOF 和 BGSAVE 同时运行会叠加 fork、内存拷贝、序列化和磁盘写入压力，实测中容易触发系统负载飙升、延迟毛刺甚至 OOM killer 杀掉 Redis 进程。一旦发生，INFO persistence 里会出现 rdb_bgsave_in_progress:1 和 aof_rewrite_in_progress:1 同时为 1 的异常状态（正常情况下二者互斥）。

如何确认当前是否已触发冲突

直接查运行时状态比翻配置更可靠：

Redis Skill - 高性能缓存管理

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

下载

• redis-cli info persistence | grep -E "(rdb_bgsave_in_progress|aof_rewrite_in_progress)" —— 若两者都为 1，说明已有逻辑绕过限制（比如手动调用 + 定时任务未错峰）
• redis-cli config get auto-aof-rewrite-percentage 和 config get save —— 看是否设置了过于激进的自动触发条件，导致重写/快照频繁争抢
• 观察日志：grep "Background.*started\|rewrite.*started" /var/log/redis/redis-server.log，检查时间戳是否密集重叠

配置层面强制错峰的实操要点

核心思路是：让 AOF 重写尽量少触发，BGSAVE 尽量不“撞车”，且失败时不中断业务：

• 禁用高频 save 规则，改用定时 bgsave：注释掉所有类似 save 60 10000 的行，改用 cron 每 2 小时执行一次 redis-cli bgsave，避开流量高峰（如凌晨 2 点、下午 3 点）
• 调低 AOF 重写的敏感度：设 auto-aof-rewrite-percentage 50（而非默认 100），并提高下限 auto-aof-rewrite-min-size 256mb，避免小文件反复重写
• 关闭写入阻塞：把 stop-writes-on-bgsave-error no，否则磁盘满或权限错时，Redis 直接拒绝所有写命令，业务立刻雪崩
• 混合持久化必须开：aof-use-rdb-preamble yes —— 这能让 AOF 重写后生成的文件包含 RDB 头部，大幅缩短重写耗时，间接降低冲突概率

最容易被忽略的隐藏坑

即使配置看起来合理，以下两点仍会导致“看似错峰、实则打架”：

• appendfsync everysec 的刷盘线程和 BGSAVE 的磁盘写入可能在毫秒级撞上——Linux 内核调度不可控，建议将 vm.swappiness 调至 1，减少 swap 干扰 I/O
• 主从架构下，从节点全量同步会强制触发主节点 BGSAVE，若此时主节点恰好在做 AOF 重写，请求会被排队等待，但监控里看不到错误，只表现为从节点 slave_repl_offset 滞后突增