对于网络 I/O 瓶颈明显的消息队列场景，Redis 6.0 多线程 IO 能带来显著提升，但如果瓶颈在于命令执行复杂度，效果则有限。
先说结论：在高频读写、大包传输的消息队列场景下效果明显，单纯依赖命令计算的场景提升有限。
- 先定位：确认当前瓶颈是网络收发而非命令逻辑。
- 先做：根据 CPU 核心数配置 io-threads 参数并重启。
- 再验证：通过基准测试对比开启前后的吞吐量变化。
配置与重启
永久生效需修改 redis.conf 配置文件，以下是关键配置项：
io-threads 4 io-threads-do-reads yes
注意：io-threads 参数通常不支持运行时动态修改，修改后必须重启 Redis 实例才能生效。操作前请确保有维护窗口，切勿在生产环境直接尝试 CONFIG SET 修改该参数。
消息队列场景压测
使用 redis-benchmark 工具针对 List 和 Stream 结构进行压测，模拟消息队列场景：
1. List 结构压测（LPUSH/RPOP）：
redis-benchmark -t list -n 100000 -r 10000
2. Stream 结构压测（XADD/XREAD）：
redis-benchmark -t stream -n 100000 -r 10000
对比开启多线程前后的 QPS 数据，重点关注吞吐量变化。
验证生效方法
1. 检查线程状态：使用 info server 命令查看 io_threads_active 字段，确认多线程已激活。
2. 观察 CPU 利用率：在高并发连接下，通过 top 命令观察 Redis 进程是否占用了多个 CPU 核心。如果多核利用率上升且延迟降低，说明配置生效。
3. 监控网络流量：通过 info stats 命令观察 instantaneous_ops_per_sec 和 instantaneous_input_kbps 的变化。
常见坑与风险
1. 线程数过多：io-threads 设置不应超过 CPU 物理核心数。超过 8 个 IO 线程后，性能提升通常不再明显，反而因上下文切换导致性能下降。
2. 小包场景：对于极小的数据包，单线程多路复用效率已经很高，开启多线程收益不大。
3. 命令复杂度：如果业务包含大量复杂命令（如 keys、大集合操作），多线程 IO 无法缓解命令执行阶段的阻塞。