redis aof重写必须用pipe通信，因为fork后子进程无法自动获取主进程的内存变更，需通过pipe将增量命令从主进程传输给子进程；aof_rewrite_buf_blocks在内存中暂存差异数据，pipe负责流式传输字节流。
Redis AOF重写为什么必须用pipe通信
因为子进程 fork 出来时只能拿到那一刻的内存快照，之后主进程的所有修改（比如新写入、删除、覆盖）都不会自动同步给子进程。要保证重写结果和当前状态一致，主进程必须把 fork 后产生的“增量变更”传给子进程。而 pipe 是 Linux 下最轻量、最可靠的父子进程单向通信机制——不需要额外依赖、不跨进程地址空间、内核原生支持。
aof_rewrite_buf_blocks 和 pipe 的分工差异
很多人混淆这两个缓冲区的作用：
-
aof_rewrite_buf_blocks是主进程在内存里维护的一组 10MB 块链表，用于暂存 fork 后收到的写命令（即“差异数据”） - pipe 是实际把
aof_rewrite_buf_blocks中已积累的数据，按需、分批、流式地推送给子进程的通道 - pipe 不缓存命令语义，只负责传输字节流；而
aof_rewrite_buf_blocks才真正承载了 Redis 协议格式的命令文本
换句话说：主进程往 aof_rewrite_buf_blocks 写，再定期把这块内容 write 到 pipe fd；子进程从 pipe fd read，解析协议，再写入临时 AOF 文件。
pipe 通信带来的真实开销点
开销不在 pipe 本身，而在它暴露出来的三个隐性成本：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 每次
write到 pipe 都触发一次系统调用，如果主进程高频写入（比如每毫秒一批），频繁write会抬高 CPU 上下文切换开销 - pipe 内核缓冲区默认大小有限（通常是 64KB），当子进程处理慢或阻塞时，主进程
write可能被阻塞（尤其在pipe满时），间接拖慢主线程响应 - 子进程需要边
read边解析 Redis 协议，再序列化成 AOF 文本写磁盘——这部分 IO + CPU 是纯额外负担，且无法并行化
注意：pipe 本身不复制数据，但 aof_rewrite_buf_blocks 的分配、填充、清空、释放全程由主进程承担，而这些操作在高负载下可能触发内存分配抖动或大页分裂（尤其当使用 2MB 大页时）。
什么情况下 pipe 开销会突然变大
不是重写启动就立刻高开销，而是以下场景会放大影响：
- 重写期间主进程写入 QPS 突增（比如批量导入），导致
aof_rewrite_buf_blocks快速膨胀，进而触发更频繁的write调用 - 子进程写磁盘慢（比如 AOF 文件落在机械盘、或磁盘 IOWait 高），pipe 缓冲区积压，主进程 write 阻塞时间拉长
- 重写缓冲区配置过小（
aof-rewrite-incremental-fsync关闭时），主进程被迫更频繁地 flush pipe，加剧系统调用密度
真正难调试的是：这种开销不会报错，也不会触发 slowlog，只会表现为客户端延迟毛刺、used_memory_rss 波动异常、或 latest_fork_usec 偶发升高——它藏在父子进程协同的缝隙里，而不是某一行代码上。
