AOF重写阻塞主线程的根本原因是fork()系统调用引发的页表复制与copy-on-write冲突；高频key修改导致大量脏页拷贝，使fork耗时飙升。
为什么AOF重写会阻塞主线程？
根本原因不在重写逻辑本身，而在 fork() 系统调用。Redis 主进程调用 fork() 创建子进程时，内核要复制父进程的页表（不是物理内存），但若启用了 copy-on-write 且此时主线程正高频修改大量 key（比如大批量写入、过期淘汰），就会触发大量页拷贝，导致 fork() 耗时飙升——你看到的“卡顿”，其实是 fork() 在等内存页状态稳定。
如何降低 fork() 阻塞风险？
核心是减少 fork 时刻主线程的内存脏页压力：
- 避免在业务高峰或大 key 清理期间手动触发
bgrewriteaof - 确保系统开启
vm.overcommit_memory = 1（Linux），否则 fork 可能因内存检查失败直接返回Cannot allocate memory - 控制单个 value 大小，尤其避免
SET bigkey "100MB string"这类操作——它会让对应内存页长期处于 dirty 状态，显著拖慢 fork - 如果使用 Redis 7.0+，可配置
aof-use-rdb-preamble yes，让重写直接复用 RDB 格式快照，跳过逐条解析 AOF 的开销，间接缩短子进程启动时间
AOF 重写过程中写入丢失吗？
不会。Redis 采用双缓冲机制：fork 后，子进程只读取当前内存快照生成新 AOF；同时主线程把所有新写命令追加到两个地方：老 AOF 文件 + 一个叫 aof_buf 的内存缓冲区；当子进程完成并发出信号后，Redis 把 aof_buf 内容原子性地追加到新 AOF 文件末尾，再原子替换文件名。整个过程写入零丢失。
但要注意：如果子进程崩溃（比如磁盘满导致 write(2) 失败），重写中止，aof_buf 仍会继续累积——此时若 Redis 挂了，未刷盘的 aof_buf 就丢了。所以务必监控 aof_last_bgrewrite_status 和磁盘空间。
重写后的 AOF 文件为何比预期大？
常见误解是“重写=压缩”，其实它只是消除冗余命令（如多次 SET k v1 → SET k v2，只留最后一条），但不会做 LZF 压缩（除非你开了 aof-rewrite-incremental-fsync yes 并配合 auto-aof-rewrite-percentage 触发）。更关键的是：
- 如果开启了
aof-use-rdb-preamble，新 AOF 开头是二进制 RDB 格式，人类不可读，但体积通常更小 - 如果重写期间有大量
EXPIRE/DEL命令，它们会被保留（因为影响数据一致性），可能让文件不缩反涨 -
appendfsync always模式下，重写子进程的写入仍走 fsync，IO 峰值高，容易被误判为“写入膨胀”
真正该盯的是 aof_current_size 和 aof_base_size 的比值，而不是文件绝对大小。
