Redis 7.0 的 GET/SET 等 String 操作提速源于网络 IO 卸载：io-threads-do-reads 负责批量读取 socket 数据至缓冲区，io-threads-do-writes 负责批量写出响应，二者运行于独立 IO 线程池，默认关闭，需显式配置 io-threads >1 且 io-threads-do-reads yes 才生效。
Redis 7.0 的 GET / SET 等 String 操作确实更快了，但提速不来自 String 本身逻辑的改动，而是网络 IO 层面的卸载——主线程不再需要亲自读取 socket、解析协议、写回响应。真正变快的是「请求进出管道」，不是「内存查键赋值」这一步。
io_threads_do_reads 和 io_threads_do_writes 是什么？
这两个函数是 Redis 7.0 多线程 IO 的核心调度入口，它们不处理业务逻辑，只干两件事：
-
io_threads_do_reads：把客户端连接的 socket 数据批量读进缓冲区（client->buf或client->querybuf），交给主线程后续解析 -
io_threads_do_writes：把主线程已生成的响应数据（client->buf/client->reply）批量写出到 socket
它们运行在独立的 IO 线程池中，默认线程数由配置项 io-threads 控制（默认为 1，即关闭多线程 IO）；启用后，主线程只负责命令执行和事件调度，IO 压力被分摊。
常见错误现象：
- 启用了
io-threads 4，但 QPS 没提升，甚至略有下降 → 很可能没配io-threads-do-reads yes（该配置默认为no，必须显式开启读多线程） - 高并发下 CPU 使用率集中在单个核上 → 忘记设置
io-threads 2或更高，或未绑定 CPU 核心（Linuxtaskset或numactl可优化缓存亲和性）
为什么 String 操作受益最明显？
因为 String 命令（GET、SET、INCR）具备三个特征：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 执行路径极短：无复杂遍历、无嵌套结构操作，通常在几微秒内完成
- 请求/响应体小：多数场景下请求包 < 100B，响应也类似，网络传输耗时占比高
- 并发连接数大：大量轻量级客户端（如微服务、前端网关）持续发起短连接或 pipeline 请求
这意味着：当网络读写从主线程剥离后，主线程能更专注地“串行跑命令”，避免被系统调用（read()/write()）阻塞，吞吐瓶颈从「网络等待」转移到「内存带宽与 L3 缓存争用」——而这正是现代服务器能轻松横向扩展的部分。
注意：
-
HGETALL或LRANGE biglist 0 -1这类返回大量数据的命令，虽然也走多线程 write，但受限于响应体大小和内存拷贝开销，收益不如GET显著 - 若启用了
tcp-nodelay no（即开启 Nagle 算法），多线程 write 可能因小包合并策略反而增加延迟，生产环境建议保持tcp-nodelay yes
配置生效的关键条件与陷阱
要让 io-threads 真正加速 String 操作，必须同时满足：
-
io-threads> 1（例如io-threads 4） -
io-threads-do-reads yes（6.0 引入，7.0 仍默认no） - 客户端使用 TCP 长连接（短连接每次 handshake + slow-start 会抵消多线程优势）
- 不与
unixsocket混用：Unix domain socket 不支持多线程 IO，此时所有配置无效
容易被忽略的一点：
Redis 7.0 的多线程 IO 仅作用于普通 TCP 连接，不涉及 AOF 重写、RDB fork、key 清理等后台任务——那些由 bio_* 线程处理，和这里无关。别指望调大 io-threads 能加快 RDB 保存速度。
String 操作变快的本质，是把原本挤在主线程里的「搬数据」动作，交给了专职搬运工。真正的计算（查 hash 表、更新 refcount、序列化 value）依然单线程完成。越简单、越频繁、越小包的操作，越能暴露这个优化的价值；而一旦命令本身开始吃 CPU（比如对 megabyte 级别 string 做 STRALGO LCS），IO 多线程带来的收益就会迅速被掩盖。
