Redis 6.0多线程仅优化网络I/O，命令执行仍为单线程；INFO stats中的instantaneous_ops_per_sec等指标反映主线程处理能力，不受IO线程影响，QPS提升源于读写加速而非命令并行化。
Redis 6.0多线程只影响网络IO，INFO 和 redis-cli --stat 仍反映单线程命令执行
Redis 6.0的多线程仅作用于 socket 读写和协议解析（即 network I/O），命令实际执行（GET、SET、事务、Lua）仍在主线程串行处理。这意味着所有传统监控指标——比如 instantaneous_ops_per_sec、total_commands_processed、used_cpu_sys、used_cpu_user——依然只统计主线程行为，**不会因开启多线程而出现“并发执行命令”的假象**。
常见误判是看到 QPS 上升就以为命令执行变并行了，其实只是连接建立、请求读取、响应写回更快了，瓶颈从网络搬到了主线程命令队列。你用 INFO stats 查到的 instantaneous_ops_per_sec 值，本质仍是主线程每秒处理完的命令数，不是 IO 线程吞吐量。
INFO clients 中的 connected_clients 和 client_recent_max_input_buffer 更敏感
多线程 IO 加速了连接接纳和请求读取，导致客户端连接堆积更少、输入缓冲区峰值更低。启用多线程后，client_recent_max_input_buffer 通常下降 20%~40%，尤其在短连接或 pipelining 场景下明显；connected_clients 的瞬时抖动也更平滑，因为主线程不再被阻塞在 read() 调用上。
- 若发现
client_recent_max_input_buffer反而升高，说明主线程已严重积压（比如有慢 Lua 或大 keySCAN），IO 线程再快也救不了 -
rejected_connections显著下降，代表 accept 队列溢出减少，这是多线程最直接的受益指标 -
blocked_clients不受多线程影响——它只统计因BLPOP、BRPOPLPUSH等阻塞命令挂起的 client，和 IO 线程无关
INFO commandstats 的延迟分布不变，但 latency doctor 可能误报
commandstats 统计的是每个命令从解析完成到执行返回的耗时（含排队时间），这个值在多线程下**不会自动拆分 IO 和执行阶段**。所以 GET 的 min/max/avg 依然包含：IO 线程读取 + 主线程排队 + 主线程执行 + IO 线程写回。如果你只看 commandstats，根本看不出多线程带来的 IO 加速效果。
redis-cli --latency 和 LATENCY DOCTOR 依赖 ping-pong 往返测时，而多线程让 pong 回复更快发出，可能触发 “max latency too high” 的误告警——实际是网络层变快了，但 latency doctor 还按旧模型解读，把 IO 提速当成 jitter 异常。
监控 agent 必须区分 io_threads_active 和 CPU 使用率
Redis 6.0 新增了 INFO threads（需 6.0.6+），其中 io_threads_active 表示当前活跃 IO 线程数，但它**不等于 CPU 占用率**。一个 IO 线程空转时也计入 active，而主线程满载时 used_cpu_sys 才真正飙升。很多监控工具（如 Prometheus + redis_exporter）默认只抓 used_cpu_sys，结果就是：开了 4 个 IO 线程，CPU 使用率却没明显变化——这恰恰说明优化生效了：原本被 IO 占用的 CPU 时间，现在由轻量级 IO 线程分摊，主线程更专注执行。
真正要盯的是：used_cpu_sys 下降 + instantaneous_ops_per_sec 上升 + rejected_connections 归零。三者同步发生，才是多线程 IO 起效的铁证。单独看任一指标都容易误判。
