AOF重写在Redis 5.0前卡主线程，因主线程需缓冲新命令并加锁同步至aof_rewrite_buf；5.0后仅fork和flush阶段短时阻塞，但磁盘I/O瓶颈仍会导致fsync延迟。
为什么 AOF 重写会卡主 Redis 主线程？
Redis 5.0 之前，aof_rewrite 是在主线程里做的：fork 出子进程后，主线程还得持续处理写命令、同时把新命令缓冲到 aof_rewrite_buf，等子进程结束再原子替换文件。这个“缓冲+同步”过程会让主线程忙于 memcpy 和锁竞争，尤其在高 QPS 场景下，容易出现延迟毛刺甚至超时报警。
- 典型现象：
INFO commandstats里rewrite命令耗时突增，latency monitor报command类型延迟 - 根本原因：重写期间主线程要维护重写缓冲区（
aof_rewrite_buf_blocks），且每次写入都要加锁，和正常命令执行抢资源 - 5.0 的改进不是“不卡”，而是把卡点从“整个重写过程”压缩到“fork 瞬间 + 缓冲区 flush 到磁盘”两个短窗口
如何确认你的 Redis 正在用新机制？
看 INFO persistence 输出里的 aof_rewrite_in_progress 和 aof_buffer_length 变化节奏 —— 如果重写期间 aof_buffer_length 大部分时间保持低位（比如 aof_rewrite_in_progress 为 1 时主线程延迟没明显升高，基本就是新机制生效了。
- 必须满足：Redis 版本 ≥ 5.0 且 配置了
auto-aof-rewrite-percentage或手动触发bgrewriteaof - 关键开关其实没有显式配置项，它由源码中
server.aof_state == AOF_ON+server.aof_rewrite_scheduled == 0自动启用 - 老版本降级回滚后，即使配置一样，也会退回旧逻辑 —— 不是配置问题，是编译时特性绑定的
重写期间写命令还丢吗？缓冲区到底存在哪？
不丢。5.0 把原来主线程直写的 aof_rewrite_buf 拆成了两级：第一级是内存块链表（aof_rewrite_buf_blocks），第二级是子进程结束后由主线程一次性刷盘的临时文件（appendonly.aof.{pid}.temp）。只要子进程没崩溃，数据就稳。
- 缓冲区实际存在堆内存里，每个 block 默认 10MB（由
AOF_REWRITE_BUFFER_BLOCK_SIZE宏控制），不会进 page cache - 如果重写中途 OOM，Redis 会 abort 子进程并清空缓冲区，此时新写入命令照常追加到原 AOF 文件，不影响可用性
- 注意
client-output-buffer-limit slave对 AOF 重写无影响，它只管复制积压，别配错地方
哪些场景下新机制仍可能拖慢服务？
当 AOF 文件本身极大（比如 >20GB）、且系统 I/O 能力弱时，子进程刷盘阶段（即重写完成后的 rename + fsync）仍会阻塞主线程几百毫秒。这不是机制缺陷，而是磁盘吞吐的物理限制。
- 典型表现：
aof_last_bgrewrite_status是ok，但紧接着aof_last_write_status变成err，日志里出现Failed to fsync the temp AOF file: No space left on device - 规避方式：调大
aof-rewrite-incremental-fsync（默认开启），让主线程分多次 fsync 小块，降低单次阻塞时长 - 真正危险的是把
no-appendfsync-on-rewrite yes和aof-rewrite-incremental-fsync yes同时开 —— 这会导致重写期间完全不 fsync，宕机就丢数据，别图省事
重写不是越勤越好，auto-aof-rewrite-min-size 设太小会导致频繁 fork，反而放大 CPU 和内存压力；生产环境建议至少 1GB 起步，配合监控看 aof_current_size 波动节奏。
