Skip to content

0002.md

Latest commit

 

History

History
174 lines (115 loc) · 4.78 KB

0002.md

File metadata and controls

174 lines (115 loc) · 4.78 KB

面试题：Redis 6 里的 Threaded I/O 是想解决什么问题？

背景：Redis 在 6.0 之前一直是 单线程模型（Single-threaded event loop）。

  • 单线程负责：网络读写 + 命令解析 + 执行 + 回复客户端
  • 虽然执行逻辑快（纯内存 + C 语言），但网络读写成为瓶颈
  • 在 10Gbps 网络时代，单线程读写 socket 已经吃不满带宽

于是 Redis 6 引入 Threaded I/O，但仅用于 I/O，不用于命令执行。

面试官想听到你能回答：

  1. Redis 为什么需要多线程 I/O？
  2. 它解决的瓶颈具体是什么？
  3. 它为什么不做多线程执行？
  4. Threaded I/O 的架构机制是什么？
  5. 带来了哪些性能提升？

下面逐条拆开。

一、Threaded I/O 要解决的核心问题是什么？

一句话：

Redis 6 的 Threaded I/O 是为了解决单线程处理“网络读写 & 协议解析”导致的吞吐瓶颈。

更具体地说：

  • Redis 核心执行逻辑（执行 SET/GET 等）快得飞起
  • 但单线程 I/O 的延迟和吞吐成了系统瓶颈
  • 客户端太多、指令量太大时，主线程无法跟上网络收发速度
  • 在高 QPS、高并发连接场景（百万连接）性能上不去

换句话说：

Redis 过去不是“CPU 不够”，而是“单线程无法吃满网卡”。

Threaded I/O 的目标是：

让 Redis 能吃满更高带宽（5GB/s 以上） → 提升吞吐。

二、Threaded I/O 解决的是哪类瓶颈？

Redis 的处理流程：

1) 接收客户端请求（IO）
2) 解析协议 RESP（IO/Parsing）
3) 执行命令（Command Execution）
4) 写回响应给客户端（IO）

Redis 单线程时代的瓶颈主要在 1、2、4：

  • 高并发连接时，网络 socket 的 read/write 很耗时
  • RESP 协议解析也耗 CPU
  • 大 key 或 pipeline 回复时，write 负担极重

Threaded I/O 就是在这些 IO 密集型步骤引入多线程，不改变执行阶段。

三、Threaded I/O 并没有让 Redis 变成“多线程执行”

许多候选人以为 Redis 6 变成多线程执行模型，这是错误的。

正确答案是：

Threaded I/O 只处理：read socket → parse → write buffer。 Redis 核心命令执行仍然是单线程。

为什么不做多线程执行？

因为：

  1. 多线程执行会导致 复杂的锁竞争（keys、dict、skiplist、LRU/LFU）
  2. Redis 的核心价值是 “逻辑单线程 = 数据天然一致”
  3. 多线程执行意味着要引入“多锁模型”，性能可能反而下降

Redis 作者 antirez 的理念：

“多线程只是为了更快地搬数据，核心执行仍然要保持单线程。”

四、Threaded I/O 的执行机制（架构级解析）

Redis 6 中执行流程变成：

主线程：
    accept 连接
    收集可读事件
    将读写任务分发给 IO 线程 (N threads)

IO 线程：
    执行 read
    协议解析（解析命令和参数）
    组装响应 write buffer

主线程：
    执行命令（仍单线程）
    IO 线程回写 socket

总结为：

  • 主线程不再被阻塞于 read/write & parse
  • 多线程能同时解析多个客户端的请求
  • 主线程只负责执行命令，利用率更高

Redis 6 引入：

io-threads 4
io-threads-do-reads yes

默认不开启，因为会增加 CPU 占用。

五、多线程 IO 带来了哪些实质提升？

官方 benchmark：

  • 在大 pipeline、小 key 高并发情况下，性能提升 2x – 4x
  • 能更好地压满 10Gbps 网卡
  • 客户端连接极多时显著改善延迟
  • 延迟波动更小

尤其是：

  • MGET/MSET
  • pipeline 500 条命令
  • 大 key 传输
  • Pub/Sub 高并发
  • 多客户端同时写大数据

提升特别明显。

六、Redis 6 的 Threaded I/O 有哪些限制？

你一定要知道这些：

  1. 命令执行仍然单线程
  2. 只在“网络读取”、“协议解析”、“网络写回”上使用多线程
  3. 在小 key、非 pipeline 场景下提升不明显
  4. 线程数并不是越多越好（CPU cache miss、争抢开销）
  5. Cluster 场景吞吐提升依旧有限（受限于 cluster 总线）

七、面试总结

你可以这样回答面试官：

“Redis 6 的 Threaded I/O 不是让 Redis 变成多线程执行，而是为了解决 Redis 单线程在高并发场景下的网络 I/O 成为瓶颈的问题。

Redis 的执行模型里，最耗时的不是命令执行，而是 socket 读写和 RESP 协议解析，所以 Redis 6 引入多线程来处理：

  • read
  • parse
  • write buffer

核心命令执行仍然是单线程，从而保证了 Redis 的一致性模型。

Threaded I/O 能显著提升 pipeline、批量命令、大 key、10Gbps 高带宽场景的吞吐性能，通常能达到 2～4 倍提升，但它不是全局多线程执行，场景有限制。”
⚡