redis 6.0 的 io-threads 仅加速网络i/o（请求读取与响应写出），不影响rdb/aof持久化；因持久化由bgsave/bgrewriteaof子进程独立完成，走磁盘i/o路径，不经过网络栈和i/o线程池。

Redis 6.0 的 io-threads 配置对持久化（RDB/AOF）完全无效 —— 持久化磁盘 I/O 仍由后台线程（bgsave / bgrewriteaof）单线程完成，不走 I/O 线程池。

为什么 io-threads 不影响 RDB 和 AOF

Redis 6.0 的多线程仅作用于「网络 I/O」：即客户端请求的读取（socket recv）和响应的写出（socket send）。而持久化是独立路径：

• RDB 快照由 bgsave 触发，fork 子进程后在子进程中全量遍历内存、序列化、写入磁盘文件 —— 这是纯磁盘 I/O + CPU 序列化，不经过网络栈，也不受 io-threads 控制
• AOF 重写（bgrewriteaof）同理，也是 fork 子进程生成新日志文件；日常 AOF 追加（appendfsync）则由主线程或后台线程同步/异步刷盘，同样与 I/O 线程池无关
• io-threads 管理的是 clients_pending_read 和 clients_pending_write 队列，只涉及 client socket，不碰 rio 文件流或 aof_buf

io-threads-do-reads yes 开启后，哪些操作会提速？

只有明确走网络路径的操作才受益，例如：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 大批量 MGET 返回多个 KB～MB 的 String 值（响应写出变快）
• 高并发短连接场景下，大量 SET 请求涌入（请求读取被分摊）
• 使用 pipeline 发送数百条命令时，首条命令的响应延迟降低（因读/写并行化）
• 但若你用 redis-cli --pipe 导入数据，瓶颈在主线程解析和内存写入，io-threads 几乎无感

想加速持久化，该调什么？

真正影响 RDB/AOF 性能的配置项与 io-threads 完全无关：

• save：控制触发 bgsave 的条件，避免过于频繁 fork
• stop-writes-on-bgsave-error yes：防止磁盘满导致 RDB 失败后继续写入脏数据
• aof-rewrite-incremental-fsync yes：让 AOF 重写时每生成 32MB 就 fsync 一次，减少单次刷盘压力
• no-appendfsync-on-rewrite yes：AOF 重写期间暂停主线程的 appendfsync，避免磁盘争抢
• 操作系统层：用 XFS 文件系统、关闭 ext4 的 barrier（需权衡安全性）、挂载时加 noatime

容易被忽略的关键点

很多人在 redis.conf 里配了 io-threads 4 就以为“Redis 多线程了”，结果压测发现 RDB 保存时间没变、AOF rewrite 卡顿依旧 —— 这不是配置错了，而是根本没作用到那个环节。网络 I/O 加速和磁盘 I/O 加速是两套机制，混用参数只会浪费调试时间。如果你的瓶颈真在持久化（比如日志写满磁盘、bgsave 耗时 > 5s），盯紧 INFO persistence 里的 rdb_bgsave_in_progress 和 aof_rewrite_in_progress，而不是去调 io-threads。