Redis 7.0集群本身并未改动集群协议或分片逻辑，性能提升的关键在于启用io-threads，增强单节点的网络I/O能力。需要显式配置io-threads和io-threads-do-reads，并通过INFO server的io_threads_active以及instantaneous_ops_per_sec来验证是否生效。
一个常被误解的点是：Redis 7.0集群并没有改动底层的集群协议或分片逻辑，它不会提供“多线程处理槽位迁移”或“多线程执行集群命令”这种能力。所谓“利用多线程模型提升大规模集群性能”，真实场景是——在集群节点上开启io-threads后，单个Redis实例（不管它是不是属于集群）的网络吞吐能力会明显增强，进而让整个集群能更稳定、更快地承载更多客户端连接和请求。
集群节点启用 io-threads 才真正影响性能
集群的性能瓶颈一直卡在单节点的网络I/O上，尤其是大量客户端并发发请求（比如PUBLISH、MGET、pipeline批量命令）时，主线程读socket、解析协议、写响应就成了串行瓶颈。7.0的io-threads正是为这个场景而生：
io-threads只负责socket读/写和协议解析，不碰数据、不执行命令，所以完全兼容集群模式下的所有语义（包括MOVED/ASK重定向、哈希槽路由、主从同步等）- 必须显式配置才生效：
io-threads 4（建议值2–8，不超过CPU核心数的75%），同时还要开启io-threads-do-reads yes（否则默认只用于写回） - 集群节点如果跑在容器或云主机上，要注意
taskset或cpuset绑核——多个I/O线程若被调度到同一物理核，反而会因为上下文切换拖慢整体吞吐
CLUSTER NODES 和 INFO cluster 看不出多线程效果
集群拓扑信息本身不会暴露I/O线程状态。你从CLUSTER NODES输出里看不到某节点开了几个线程，靠INFO cluster也没法判断是否启用多线程。真正要确认是否生效，得看下面几项：
INFO server中的io_threads_active字段：值为1表示I/O线程已就绪并参与工作INFO stats中的instantaneous_ops_per_sec峰值是否明显高于6.x同配置实例（通常提升40%~90%，取决于网络包大小和并发连接数）- 用
redis-cli --intrinsic-latency 100测试，开启多线程后平均延迟抖动会更小，尤其在高负载下
集群广播类命令（如 PUBLISH）受益最直接
在集群直连模式下，PUBLISH默认广播到所有master节点（Redis 6.0+行为）。这意味着每个节点都要处理大量入站消息加上多个出站响应。这时候io-threads的价值最突出：
- 多个线程并行从不同客户端socket读取
PUBLISH请求，避免主线程阻塞在某一个慢连接上 - 响应写回也由I/O线程异步完成，主线程可以立即继续处理下一个命令（比如事务或Lua）
- 注意：广播带来的带宽压力仍然存在，
io-threads并不减少网络流量，只是加速收发过程
一个容易被忽略的细节是线程与内存分配器的协同——如果用的是jemalloc，务必确保版本≥5.2.1；glibc malloc在高并发小对象分配下很容易成为隐性瓶颈，这一点在集群多节点部署时会被指数级放大。
