Redis 6.2 未改进所谓“AOF重写管道”，因该机制根本不存在；实际改进的是AOF重写子进程的CPU绑定策略，通过aof-rewrite-cpulist降低与主线程的资源争抢。
Redis 6.2 并没有对“AOF重写管道”做出任何改进——根本不存在所谓“AOF重写管道”这个机制。 这个说法混淆了两个完全独立的概念：pipeline（客户端命令批量发送机制）和 AOF rewrite（服务端后台子进程重写日志文件的过程）。它们在实现层、调用方、数据流向和作用域上均无交集。
为什么有人会把 pipeline 和 AOF 重写扯在一起
常见误解来源有三个：
- 看到“pipeline”和“AOF”都出现在 Redis 文档里，误以为它们协同工作
- 误读了 AOF 重写过程中“子进程生成命令序列”这一描述，脑补成“把命令塞进 pipeline 执行”
- 混淆了
redis-cli --pipe工具的用途：它只是把文本命令流喂给 Redis，和 AOF 重写无关；重写子进程根本不走网络协议栈，也不解析 RESP，而是直接遍历内存结构生成最小化命令文本
真正被 Redis 6.2 改进的是 AOF 重写的 CPU 调度与 I/O 协作逻辑
6.2 引入的关键配置是 aof-rewrite-cpulist，它解决的不是“管道”，而是重写子进程和主线程之间的资源争抢问题：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 默认情况下，AOF 重写子进程和主线程可能跑在同一个物理 CPU 核上，导致 L1/L2 cache 频繁失效、TLB miss 上升、内存带宽打满
-
aof-rewrite-cpulist 2,3可显式绑定重写子进程到特定核，但前提是 Linux 内核调度未启用节能模式（需确认/proc/sys/kernel/sched_smt_power_saving值为0） - 该配置不改变重写逻辑、不减少写放大、不加速命令生成，只降低重写期间对主线程吞吐和延迟的干扰
如果你真在 AOF 重写期间观察到性能抖动，优先排查这些点
别盯着不存在的“管道”，先看真实瓶颈：
- 检查
INFO persistence中的aof_rewrite_in_progress和aof_current_rewrite_time_sec，确认是否真处于重写中 - 用
top -H -p $(pgrep redis)观察线程 CPU 占用，区分主线程 vs 重写子进程（子进程 PID 不在redis-server主进程树下，ps看不到） - 确认
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size是否设置过激（如设成50+1mb），导致重写过于频繁 - 注意重写子进程会 copy-on-write 内存页，若实例内存碎片率高或使用了大量 small object，fork 开销可能远超预期
真正影响 AOF 重写效率的，从来都不是“管道”，而是 fork 成本、内存布局、CPU 绑核策略和磁盘 I/O 调度。把精力放在这些地方，比寻找一个根本不存在的“重写管道优化”实在得多。
