根本原因是AOF重写子进程与主线程竞争aof_rewrite_buf锁，高写入下缓冲区频繁扩容、COW页表复制及I/O压力叠加导致卡顿；需通过错峰调度、预留内存、启用incremental-fsync等优化。
为什么AOF重写期间Redis变慢甚至卡顿
根本原因是重写过程本身不阻塞主线程，但重写子进程需要从主线程的AOF重写缓冲区（aof_rewrite_buf）持续读取增量命令，而主线程写入该缓冲区时存在锁竞争。尤其在高写入场景下，aof_rewrite_buf可能频繁扩容、内存拷贝加剧，同时子进程fork开销叠加页表复制（COW），导致系统负载陡增。
实操建议：
- 确认是否真由AOF重写引发：观察
INFO persistence中aof_rewrite_in_progress:1与aof_current_rewrite_time_sec是否长期非零，同时比对used_cpu_sys_children是否突增 - 避免在业务高峰触发重写：禁用自动重写（
auto-aof-rewrite-percentage 0），改用人工调度，例如凌晨低峰期执行BGREWRITEAOF - 确保足够内存：重写子进程会复制父进程页表，若实例内存超10GB，需预留至少20%空闲内存，否则易触发swap或OOM killer
如何调小AOF重写缓冲区的副作用
aof_rewrite_buf默认无固定大小上限，全靠内存动态分配，写入密集时容易产生大量小块内存申请和碎片。这不是配置项可直接设大小，但可通过控制其“被消费的速度”来间接缓解压力。
实操建议：
- 增大
client-output-buffer-limit normal不影响它，但要检查client-output-buffer-limit slave——如果从节点同步慢，会导致主节点积压更多待传播命令，间接拖慢aof_rewrite_buf清理节奏 - 启用
aof-rewrite-incremental-fsync yes：让子进程每写入32MB就调用一次fdatasync，减少单次刷盘压力，避免I/O阻塞子进程读缓冲区 - 不要调高
hz值来“加速”重写——反而会增加主线程定时任务负担，恶化锁争用
重写期间数据一致性靠什么保障
不是靠锁，也不是靠事务，而是靠三段式写入：主线程写原AOF文件 + 写aof_rewrite_buf；子进程只读aof_rewrite_buf并生成新AOF；重写完成后原子替换文件。只要子进程没退出，aof_rewrite_buf里的命令就一定不会丢失。
实操建议：
- 崩溃恢复时，Redis优先加载新AOF文件，再回放重启后追加到旧AOF末尾的那部分（即重写开始后新增的命令），这部分记录在
aof_buf中，不是aof_rewrite_buf - 若重写中途失败，新AOF文件被删除，但原AOF+内存中未落盘的
aof_buf仍完整，不影响数据安全 - 注意
no-appendfsync-on-rewrite yes的风险：虽然能降低磁盘压力，但若此时发生宕机，自上次fysnc以来的原AOF数据将丢失——这和重写无关，是全局策略
哪些配置组合实际会拖垮重写性能
单独看每个参数都合理，但合在一起就容易出问题。最典型的是日志级别+持久化策略+子进程行为叠加影响。
实操建议：
- 禁用
save ""后仍开启AOF，不代表更安全——若同时配置appendfsync everysec和aof-rewrite-incremental-fsync yes，每秒两次fdatasync调用（主流程+子进程）可能打满磁盘IOPS -
maxmemory-policy allkeys-lru在重写期间可能意外触发驱逐，导致key变更频率升高，进一步放大aof_rewrite_buf写入量 - 使用RDB+AOF混合持久化（
aof-use-rdb-preamble yes）时，重写会先生成RDB头再追加AOF命令，虽减小体积，但RDB序列化阶段CPU占用更高，需监控used_cpu_sys是否持续超0.8
真正难处理的不是参数本身，而是重写过程中主线程与子进程对同一块共享内存（aof_rewrite_buf）的读写节奏错配——它不报错，只悄悄拖慢响应，得靠redis-cli --stat盯住repl-backlog-active和aof-pending-bio-fsync这两项才容易发现苗头。
