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里显示命令本身执行时间就很长——这些活儿，线程池压根不参与。 - 线程数设置建议：通常从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且数据包很小的场景下，这种“过度优化”很容易产生负效果。
- 性能拐点：通常，当平均每个IO线程处理的连接数少于100个时，收益就开始急剧衰减。比如，4个线程处理400个以上的连接比较稳健；但如果总共只有50个连接，却开了6个线程，那收益微乎其微，开销反而增加了。
- 系统内核参数：别忘了检查Linux系统的网络参数，比如
/proc/sys/net/core/somaxconn和net.core.netdev_max_backlog。如果线程池开大了，但内核的连接队列太小，请求照样会丢包、重传，性能自然上不去。 - 客户端连接模式：如果客户端虽然使用了长连接，但复用率很低（比如每个请求都新建连接），那么线程池无法有效复用连接上下文，效果也会大打折扣。
io-threads和Redis线程模型的关系
必须明确一个概念：Redis 6采用的依然是「单主线程+多IO线程」的混合模型，它并非一个真正的、所有操作都并行化的多线程Redis。所有核心的数据结构操作、过期键清理、AOF重写、RDB快照生成，这些重量级任务仍然牢牢掌握在主线程手中。
还有一个容易被忽略的设计细节：io-threads的各个线程之间并不共享客户端连接。每个client socket在建立时，就会通过一个哈希取模算法被固定绑定到某一个IO线程上。这就意味着，当连接数突然激增时，可能会出现某些线程瞬间过载，而其他线程却相对空闲的情况。这并非程序的bug，而是有意为之的设计。
所以，在做压测时，如果观察到某个IO线程的CPU使用率飙升，而其他线程却很闲，先别急着调整线程总数。不妨先检查一下，客户端的连接分布是否均匀地散落到了各个线程上。这才是关键所在。
