根因是父进程在每次事件循环中同步拷贝新写命令至重写缓冲区，该操作阻塞、高频且不可批处理；QPS高、命令短小时拷贝开销直接导致CPU持续90%+。
bgrewriteaof期间CPU飙升的根因是父进程同步拷贝命令到重写缓冲区
不是子进程在“计算”，而是父进程在每次事件循环中，把新来的写命令同步复制进 aof_rewrite_buf_blocks ——这个动作是阻塞式、高频、不可批处理的。当QPS高（比如 > 5k）、命令短小（INCR、SET），拷贝开销直接反映为 CPU 占用率持续 90%+。
常见错误现象：top 显示 redis-server 进程 CPU 飙升；INFO persistence 中 aof_rewrite_in_progress:1 且 aof_current_rewrite_time_sec 长时间不归零；客户端延迟明显升高。
- 别在写入高峰期手动触发
bgrewriteaof - 检查是否启用了
auto-aof-rewrite-percentage但auto-aof-rewrite-min-size设得太小（如1mb），导致几分钟就重写一次 - 确认没有多个后台任务并发：AOF 重写和
bgsave不能同时进行；若配置了save 60 10000又频繁写入，可能因等待 RDB 结束而堆积重写请求
no-appendfsync-on-rewrite=yes 对CPU无缓解作用
这个配置只影响父进程在重写期间是否暂停 fdatasync，对“命令拷贝”本身完全没影响。开启后，AOF 日志落盘被延迟，极端情况下可能丢失最多 1 秒数据（取决于 appendfsync 设置）。
性能影响：CPU 使用率几乎不变，但磁盘写入毛刺更平滑；兼容性上，所有 Redis 2.8+ 都支持，但若业务要求强持久化（如金融类事务日志），此选项不可用。
- 仅在
appendfsync everysec且允许秒级数据丢失时启用 - 绝对不要在
appendfsync always下设为yes——配置冲突，Redis 启动会报错：ERROR: Invalid argument for config 'no-appendfsync-on-rewrite'
如何安全调低 AOF 重写频率
核心不是“禁用”，而是让重写真正符合业务节奏：既避免太勤（CPU 压力），又防止太大（重写耗时长、失败风险高）。
- 把
auto-aof-rewrite-percentage从默认100提高到200或300（即 AOF 增长 2–3 倍才触发） -
auto-aof-rewrite-min-size至少设为64mb，避免小文件频繁重写；若日均增长500mb，可设为256mb - 确保
aof-rewrite-incremental-fsync为yes（默认），它会让子进程每写32MB就刷一次磁盘，降低单次 I/O 压力
重写期间内存暴涨和CPU飙升常伴生，但成因不同
CPU 飙升来自父进程命令拷贝，内存暴涨则主要来自三块：fork 后 COW 触发的页拷贝、aof_rewrite_buf_blocks 缓冲区累积、以及慢速磁盘导致的临时文件页缓存堆积。这两者容易被混为一谈，但调优手段完全不同。
例如：你看到 used_memory_peak 突增 + top CPU 拉满，第一反应不该是“加内存”，而是查 INFO stats 中的 aof_pending_rewrite 和 aof_rewrite_in_progress，再结合日志里有没有反复出现 “Starting automatic rewriting of AOF on signal” ——这往往意味着自动触发条件失控，比任何参数微调都更紧急。
