多线程网络收发
Redis 6.0 起可以把网络读写分发到多个 IO 线程，命令执行仍由主线程串行完成。也就是说，它解决的是「网络收发成为瓶颈」的问题，命令本身的耗时不会被并行化；网络负载重、单核收发吃满的实例开了它才可能有收益。
基本信息
| 配置项 | io-threads N，默认 1 表示关闭 |
|---|---|
| 读取分发 | io-threads-do-reads yes 后读取也走多线程 |
| 版本 | Redis 6.0 起 |
| 线程数建议 | 不超过可用核数，通常小幅上调 |
典型使用场景
- 网络收发占用主线程明显，单核被收发吃满
- 大量连接或大包体放大网络层开销
- 压测中确认命令层是否已经成为真正瓶颈
- 多核机器上 CPU 利用率长期不均衡
- 扩容前尝试先从网络并行里榨出余量
调整与验证
调整与验证
# 查看当前线程配置
redis-cli CONFIG GET io-threads io-threads-do-reads
# 小幅上调 IO 线程，不要超过可用核数
redis-cli CONFIG SET io-threads 4
redis-cli CONFIG SET io-threads-do-reads yes
# 观察吞吐变化，注意对比时压测参数必须一致
redis-benchmark -t set,get -n 200000 -c 100 -P 16 -q
# 看命令级统计，判断瓶颈在命令还是网络
redis-cli INFO commandstats | head -10参数读法
| 参数 | 含义 | 注意点 |
|---|---|---|
| io-threads | 参与网络读写的线程数 | 默认 1 即关闭多线程 IO |
| io-threads-do-reads | 是否启用多线程读取 | 关闭时只有写入被分发 |
| 可用核数 | 决定线程数的上限 | 超过可用核数会抬高协调成本 |
| 命令执行 | 仍在主线程串行 | 命令慢调这个参数没有帮助 |
| 网络开销 | 与连接数和包体大小相关 | 管道化与小包能降低单请求开销 |
判断是否值得开启：先看命令执行耗时与网络收发耗时的占比；如果命令本身就慢，增加 IO 线程只会让排队现象更明显。
线程数盲目设大，上下文切换与线程间协调开销上升，吞吐可能不升反降；任何改动都要用同一套压测参数对比，不能凭感觉。