Redis6的io-threads仅加速网络IO（读写socket、协议解析、响应打包），不加速命令执行；命令仍由主线程串行处理，IO线程仅分担“搬运”工作。
Redis6的io-threads到底管什么
它只加速网络IO（接收命令、发送响应），不加速命令执行本身。所有命令仍在主线程串行执行，io-threads只是把socket读写、协议解析、响应打包这些“搬运工”活分出去干。
常见错误现象：INFO commandstats里cmdstat_get耗时没降，但整体QPS上去了——说明IO瓶颈被缓解了，真正慢的命令还是慢。
- 适用场景：高并发小包请求（如大量
GET/SET）、客户端连接数多、网卡或CPU在IO等待上明显打满 - 不适用场景：大key操作（
LRANGE biglist 0 -1）、Lua脚本、SLOWLOG里显示命令执行时间长——这些线程池完全不参与 -
io-threads数量建议从2起步，最大别超CPU核数的75%，比如8核机器设为4～6；设为1等于关闭，设为0会报错启动失败
怎么开io-threads并调数量
必须同时配两个参数，缺一不可，否则线程池不生效：
- 在
redis.conf里加：io-threads 4（线程数，必须≥2才启用多线程） - 再加：
io-threads-do-reads yes（默认no，不设这句，线程池只处理写，读仍主线程扛） - 改完重启Redis，用
INFO server确认io_threads_num字段值是否匹配
注意：热重载不支持这两个配置，CONFIG SET会报错，必须重启。
为什么开了io-threads反而变慢了
典型原因是线程数设太高，引发上下文切换和锁竞争，尤其在低并发或SSD+小数据场景下负优化。
- 性能拐点通常出现在每线程处理连接数＜100时，比如4个线程配400+连接较稳；若只有50连接却开6线程，收益极小还增开销
- Linux下需检查
/proc/sys/net/core/somaxconn和net.core.netdev_max_backlog，线程多了但内核连接队列太小，照样丢包、重传 - 客户端用长连接但复用率低（比如每个请求建新连接），线程池无法复用上下文，效果打折
io-threads和Redis线程模型的关系
Redis6仍是「单主线程+多IO线程」，不是真正的多线程Redis。所有数据结构操作、过期键清理、AOF重写、RDB生成，全在主线程。
容易被忽略的一点：io-threads线程间不共享连接，每个client socket固定绑定一个IO线程（哈希取模分配），所以连接数突增时，某些线程可能瞬间过载，而其他空闲——这不是bug，是设计如此。
压测时如果看到某线程CPU飙高而其他偏低，先看连接分布是否均匀，别急着调线程数。
