Redis6如何利用多线程提升网络读写吞吐量_开启io-threads并调整线程池数量

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使用率飙升，而其他线程却很闲，先别急着调整线程总数。不妨先检查一下，客户端的连接分布是否均匀地散落到了各个线程上。这才是关键所在。