redis 6.0主从复制吞吐量瓶颈在网络i/o，多线程仅优化socket读写：必须同时启用io-threads和io-threads-do-reads（默认关闭），且io-threads≥2才生效；线程数推荐min(4, cpu核心数×0.7)，超配反致性能下降。
Redis 6.0 的主从复制吞吐量瓶颈不在命令执行，而在网络 I/O —— 多线程配置只对复制流量的读写环节生效，且必须同时开启 io-threads 和 io-threads-do-reads，否则完全无效。
为什么主从复制能从多线程 I/O 受益
主从复制本质是持续的网络数据流：主节点把写命令（或 RDB + 增量命令）打包发给从节点，从节点接收并解析执行。这个过程里，socket read()（从节点读取主节点数据）和 socket write()（主节点发送数据）占 CPU 时间比例极高，尤其在以下场景：
- 全量复制时传输大 RDB 文件（几十 MB～GB 级）
- 增量复制中主节点写入频繁、
repl-backlog-size设置较大 - 从节点数量多（如 1 主 5 从），主节点要并发写多个 socket
这些操作原本全压在主线程上，启用 I/O 多线程后，read() 和 write() 被分摊到多个线程，主线程腾出资源专注处理复制协议解析与命令分发。
io-threads 和 io-threads-do-reads 必须成对启用
这是最容易踩坑的地方：只改 io-threads 4，不设 io-threads-do-reads yes，配置等于白配。原因在于：
-
io-threads-do-reads no是 Redis 6.0 默认值，意味着 I/O 线程只参与write（主节点发数据、从节点回 ACK），不参与read（从节点收命令流） - 主从复制中，从节点的
read压力往往更大（要连续接收大量命令），漏掉这一步，90% 的加速机会就丢了 -
io-threads值必须 ≥ 2 才真正创建线程；设为 1 等价于禁用
正确配置示例（写入 redis.conf）：
io-threads 4 io-threads-do-reads yes
修改后必须执行 redis-cli config rewrite 或重启，config set 不支持热更新这两个参数。
线程数不是越多越好，主从角色要分开调优
主节点和从节点对 I/O 线程的需求不同，不能简单套用同一套数值：
-
主节点：重点优化
write并发能力，线程数可稍高（如 4～5），但需观察INFO threads中的io_threads_active是否稳定在高位；若频繁波动，说明线程数超配 -
从节点：重点优化
read吞吐，尤其在全量同步阶段。建议从io-threads 3起步，配合io-threads-do-reads yes，再根据top -H -p $(pidof redis-server)查看线程 CPU 占用是否均衡 - 线程数推荐公式：
min(4, CPU核心数 × 0.7)。例如 8 核机器，主节点设 4，从节点设 3；16 核可设到 5，但超过 6 很少带来收益
超配典型表现：%sy（系统态 CPU）飙升、QPS 不升反降、INFO stats 中 instantaneous_ops_per_sec 波动剧烈。
别忽略复制链路上的其他瓶颈点
I/O 多线程只是复制吞吐提升的一环，以下三点没调好，线程再多也白搭：
-
复制缓冲区大小：
repl-backlog-size过小会导致频繁全量复制，抵消 I/O 加速效果；建议 ≥ 512mb（大实例可设 1gb～2gb） -
内存分配器：确认使用
jemalloc（非libc malloc），否则大 RDB 加载时内存分配卡顿会拖慢整个流程 -
CPU 绑定：通过
server_cpulist把 Redis 主进程和 I/O 线程绑到固定核（如server_cpulist 0-3），避免跨核调度开销；后台bio线程建议另绑一组核（如bio_cpulist 4-5）
最常被忽略的是：I/O 线程只管“搬数据”，但 RDB 文件加载、AOF rewrite、key 大量过期清理这些重操作仍在主线程。如果复制期间主线程被 lazyfree-lazy-eviction 或 active-defrag 拖住，吞吐照样上不去。
