Redis禁止BGSAVE与BGREWRITEAOF并发执行，是为避免双子进程争抢CPU、I/O、COW内存页及fsync队列；前者返回错误，后者被排队；no-appendfsync-on-rewrite yes可缓解AOF重写时主进程fsync阻塞，但对BGSAVE无效。
为什么 BGSAVE 和 BGREWRITEAOF 不能同时运行
Redis 主动禁止两者并发，不是因为底层逻辑冲突（比如共享文件锁或内存竞争），而是出于资源保护的硬性策略：避免两个子进程同时做大量磁盘写入，拖垮 CPU、I/O 和内存拷贝开销。哪怕机器有 32 核，fork 出的两个子进程仍会争抢页表复制、写时复制（COW）内存页、磁盘带宽和 fsync 队列。
具体表现是：BGREWRITEAOF 正在执行时，客户端发 BGSAVE 命令，Redis 直接返回错误：ERR Background save already in progress；反过来，BGSAVE 运行中发 BGREWRITEAOF，命令不会报错，但会被排队挂起，等 BGSAVE 完成才真正开始。
-
SAVE和BGSAVE共用rdbSave()函数，所以必须互斥，否则父子进程可能同时写同一份内存结构 -
BGREWRITEAOF虽然走另一套逻辑（读取当前数据重生成 AOF），但它同样要 fork 子进程、遍历全部 key、序列化命令——这和BGSAVE的资源压力模式高度重叠 - Redis 没有“优先级抢占”机制，只有“先到先服务 + 显式拒绝”，所以没有配置能绕过这个限制
no-appendfsync-on-rewrite yes 是什么，它真能缓解阻塞吗
能，但只解决其中一类阻塞——由主进程 fsync() 被子进程 I/O 卡住的问题。当 appendfsync everysec 开启时，主进程每秒调一次 fsync()，而 BGREWRITEAOF 子进程也在狂写磁盘，内核 I/O 队列一拥而上，主进程就卡在 fsync() 系统调用里，导致所有请求超时。
设为 no-appendfsync-on-rewrite yes 后，只要子进程在重写 AOF，主进程就跳过本该做的 fsync()，只做 write()，把数据交给内核缓冲区。风险是：若此时机器断电，最多丢失最近 1 秒 AOF 缓冲数据（和 everysec 本身承诺一致），但至少 Redis 不会卡死。
- 这个配置对
BGSAVE无效，它只影响 AOF 重写期间的主进程 fsync 行为 - 若你用的是
appendfsync always，此配置不生效——因为always每次写都强制落盘，无法跳过 - 生产环境建议搭配监控：用
INFO persistence查看aof_rewrite_in_progress和rdb_bgsave_in_progress是否长期为 1，判断是否被卡住
如何安全地安排持久化任务，避开高峰期
别依赖“Redis 自己选时间”，它的自动触发（如 save 60 10000）是被动响应写入量，容易撞上业务高峰。更可控的方式是人工调度 + 主从分离角色。
- 禁用 Master 的自动 RDB 触发：在 master 配置中注释掉所有
save行，只靠BGSAVE手动或定时触发 - 让 Slave 承担
BGSAVE：在某个低峰 Slave 上执行redis-cli -h slave-ip bgsave，生成 RDB 后手动同步到备份机，Master 完全不碰磁盘写 - 把
BGREWRITEAOF改成每天固定低峰执行，例如凌晨 2 点，且确保此时没其他运维任务（如日志轮转、备份脚本）在刷磁盘 - 检查是否有残留定时任务：就像某次真实事故——Master 切换后旧的
bgrewriteaofcrontab 没删，结果每天准时卡服务 5 分钟
监控与诊断：怎么知道是不是被持久化卡住了
别等用户报警才查。Redis 提供了几个关键指标，直接反映子进程状态和主线程健康度。
- 用
redis-cli info persistence看：rdb_bgsave_in_progress:0、aof_rewrite_in_progress:0应为 0；非零值持续超过 5 分钟就要警惕 - 关注
latest_fork_usec：单位是微秒，如果它突然飙升（比如从 10ms 变成 500ms），说明 fork 开销变大，可能是内存碎片高或 COW 内存页太多 - 结合系统层看：
iostat -x 1观察%util和await，若重写期间await> 100ms，基本可判定磁盘成了瓶颈 - 注意
used_memory_rss和used_memory差值：若差值过大（比如 RSS 是内存的 2 倍），说明 COW 复制页太多，fork 成本极高，此时应减少大 key 或考虑关闭 AOF
子进程排他不是 bug，是 Redis 在单线程模型下守住响应性的底线。真正麻烦的不是它“不允许并发”，而是你没意识到：一次 BGREWRITEAOF 可能让内核 I/O 队列堵死，而这个堵点，连 redis-cli ping 都穿不过去。
