redis 6.2 的 io-threads 对 aof 重写完全无效，因其仅处理网络读写，不参与 bgrewriteaof 的 fork、键遍历和文件写入；重写全程由主线程触发、子进程串行执行，与 io-threads 无任何交集。
AOF重写期间的写放大问题，Redis 6.2 仍无法靠 io-threads 缓解——因为 io-threads 不参与重写逻辑，只管网络收发。
为什么 io-threads 对 AOF 重写完全无效
Redis 6.2 的 io-threads 仅用于处理客户端连接的读写事件（readQueryFromClient / prepareClientToWrite），而 bgrewriteaof 全程由主线程触发、fork 子进程执行、子进程串行遍历键空间并写入新文件。整个过程不经过 io-threads 线程池，也不走网络事件循环。
常见错误现象：
- 启用了
io-threads 4，但INFO stats中used_cpu_sys_children仍飙升，重写耗时未下降 - 监控显示 io-thread CPU 占用率始终低于 5%，而主线程和子进程 CPU 持续打满
真正影响写放大的是 fsync 执行时机与缓冲区协同
写放大主因不是“写得多”，而是“同一块 SSD 扇区被反复擦除+搬移”：AOF 重写生成大文件 + 主线程持续追加新命令 + fsync 集中刷盘，三者叠加造成 I/O 密集型毛刺。
关键实操建议：
- 必须设
no-appendfsync-on-rewrite yes：否则主线程的everysecfsync 和子进程的重写写入会在 SSD 上直接竞争，写放大翻倍 - 启用
aof-rewrite-incremental-fsync yes（默认）：让子进程每写入 32MB 就调一次fdatasync()，避免最后一次性刷几十 GB 导致 I/O hang - 禁用
appendfsync always：该模式下重写期间主线程仍每条命令都fsync，与子进程形成稳定写放大源，生产环境应杜绝
Redis 6.2 新增的 aof-rewrite-cpulist 能起作用吗
可以，但作用有限且易被忽略。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
aof-rewrite-cpulist 是 Redis 6.2 引入的配置项，用于绑定重写子进程使用的 CPU 核心（如 aof-rewrite-cpulist 2,3）。它不减少写放大本身，但能降低以下两类干扰：
- 避免重写子进程与主线程争抢同一物理核的 L1/L2 cache，减少 TLB miss 和内存带宽争用
- 防止重写期间
used_cpu_sys波动引发内核调度抖动，间接稳定 I/O 提交节奏
注意：aof-rewrite-cpulist 仅在 Linux 上生效，且需确认 /proc/sys/kernel/sched_smt_power_saving 为 0（关闭节能调度），否则绑核可能失效。
最常被漏掉的硬件层动作：SSD 的 I/O 调度与挂载参数
即使参数全调优，若底层存储没对齐，优化效果归零。
必须检查并落实：
- AOF 文件路径（
dir）和临时重写文件（appendfilename）在同一挂载点，且该挂载点使用noatime,nodiratime挂载 - SSD 设备使用
none或kyberIO scheduler（避免cfq或mq-deadline在高吞吐下引入延迟） - 禁用 ext4 的
journal=ordered，改用data=writeback（需 UPS 保障，否则断电可能丢元数据）
真正难的是：这些设置跨内核、文件系统、存储设备三层，任一环节错配，都会让 aof-rewrite-cpulist 和 incremental-fsync 白调。
