多线程？就是Redis 线程模型：单线程还

文章目录

• 一、Redis 是否为单线程？
• • Redis 的线程组成
• 二、为什么采用单线程处理命令
• • 2.1 单线程的局限
  • 2.2 任务类型与优化策略
  • • 2.2.1 IO 密集型任务
    • 2.2.2 CPU 密集型任务
  • 2.3 为什么不直接用多线程来处理命令？
• 三、Redis 的 IO 多线程工作原理
• • 3.1 Reactor 模型流程
  • 3.2 为什么需 IO 多线程
  • 3.3 多线程下的执行方式
  • 3.4 多线程启用

否为单线程？就是一、Redis

Redis 通常被描述为“单线程”的数据库，但这种说法并不完全准确。Redis 的命令处理（核心业务逻辑）是单线程的，但它在运行时还会配合多个后台线程或辅助线程：就是执行一些耗时或异步任务。因此，更准确的说法Redis 的核心命令处理是单线程的，但整体运行机制是多线程协作的。

Redis 的线程组成

Redis 的 redis-server 线程是核心业务线程，核心负责两项关键工作：一是命令处理，即接收、解析并执行客户端发送的命令；二是网络事件监听，实时监测客户端与 Redis 之间的网络连接状态及数据传输情况。

• 主线程（redis-server）：负责命令解析、执行以及网络事件监听我们说的“单线程命令处理”。就是，也就

• 后台异步线程（BIO）：

  • bio_close_file：负责异步关闭文件（例如 RDB 或 AOF 文件），避免主线程等待 IO。
  • bio_aof_fsync：负责异步执行 AOF 刷盘操作。
  • bio_lazy_free：异步释放大块内存，防止阻塞主线程。

• IO 多线程（io_thd_xxx）：用于在高并发下并行处理网络信息的读写，减轻主线程的 IO 压力。

• jemalloc 背景线程：jemalloc_bg_thd 是 Redis 默认使用的内存分配器的后台清理线程，用于优化内存碎片。

---

二、为什么采用单线程处理命令

2.1 单线程的局限

单线程的核心问题是无法承载耗时操作，一旦执行耗时操作，会直接阻塞整个 Redis 服务，严重降低其响应性能。对 Redis 而言，需规避的耗时操控主要有两类：

• 耗时的CPU 运算：例如复杂的数学计算、对大规模数据的遍历操作等，这类操作会长时间占用 CPU 资源，导致核心线程无法处理其他命令；

• 阻塞的IO 操作：例如同步的磁盘写入（数据直接写入磁盘且需等待写入做完）、同步的网络读写（等待网络数据传输完成后再执行后续操作），这类操作会让核心线程处于等待状态，无法高效处理命令。

2.2 任务类型与优化策略

Redis 的任务负载既含有大量IO 操作（磁盘 IO、网络 IO），也涉及少量CPU 运算。Redis 针对这两类任务采用了不同的优化方式。

2.2.1 IO 密集型任务

异步化 + 多路复用 + 多线程辅助

磁盘 IO 的优化

：就是Redis 需要将内存数据持久化到磁盘（RDB 快照或 AOF 日志），但这些操作耗时很长。 Redis 的策略

• RDB 持久化：通过 fork 创建子进程，让子进程执行 RDB 快照生成工作，即把内存中的数据完整备份到磁盘，而主进程继续处理命令；
• AOF 刷盘异步化：对于 AOF 持久化（记录每一条写命令到档案），Redis 采用异步刷盘方式，由bio_aof_fsync后台线程负责将 AOF 缓冲区的命令写入磁盘，核心线程只需将命令写入缓冲区即可，无需等待磁盘写入结束。

网络 IO 的优化

Redis 是典型的网络服务器，需同时处理大量客户端的命令请求，当数据请求或返回数据量较大时，网络 IO 压力会显著增加。它采用了高效的Reactor 模型（IO 多路复用）：

• 通过 epoll、select 等系统调用，Redis 能在单线程中监听多个客户端的 IO 状态。不应该为每个客户端分配一个独立线程或进程，极大减少了系统开销。
• 一旦某个 IO 就绪，就通过回调机制立即处理信息；
• 在极端高并发场景下，Redis 会开启 IO 多线程（io_thd_xxx）专门处理这些耗时的 IO 操作，让多个线程并行处理读写请求，减少核心线程的阻塞。

2.2.2 CPU 密集型任务

Redis 虽存在 CPU 运算场景，但通过 “算法优化、数据结构适配”，让单线程也能高效处理 CPU 密集任务，无需依赖多线程：

（1）分治方式优化

对于艰难的 CPU 运算任务，Redis 采用 “分而治之” 的思路，将大问题拆分为多个独立的小问题，单线程逐个解决小问题，避免因一次性处理大难题导致的 CPU 长时间占用。

（2）数据结构动态切换

Redis 的五大根本数据结构（string、list、hash、set、zset）均提供多种实现方案，会根据数据量大小、资料存储类型自动选择最高效的结构，减少 CPU 运算耗时。例如 list 结构，当数据量较小时采用压缩列表（ziplist），数据量较大时自动切换为双向链表（linkedlist），两种结构分别适配不同数据规模，确保 CPU 处理效率。

（3）渐进式数据迁移

对于大的耗时任务（如大 key 迁移、数据结构重构），Redis 将其拆分为多个耗时短的小任务，单线程分阶段、分批次执行，每次仅处理一个小任务，处理达成后先返回处理其他命令，后续再继续执行下一个小任务，避免单次管理耗时过久阻塞核心线程。

2.3 为什么不直接用多线程来处理命令？

如果用多线程来处理命令，会带来一系列问题，反而可能抵消多线程的性能优势：

1. 加锁复杂度高

• Redis 的核心数据结构并非独立隔离的对象，而是高度共享的全局状态；
• 如果多个线程同时运行这些结构，必须加锁保护；
• 锁的粒度很难控制，容易引发死锁、性能抖动或锁竞争；
• 反而破坏了 Redis 的轻量特性。

2. 上下文切换开销大

• 多线程需要频繁保存和恢复执行状态（上下文切换），这本身会消耗 CPU；
• 若是管理粒度较小，此种切换成本甚至高于并行带来的收益。

---

三、Redis 的 IO 多线程工作原理

Redis 的事件处理基于Reactor 模型，通过 epoll 等 IO 多路复用机制，让少量线程同时监听多个 socket 的 IO 状态；当某个 socket 可读 / 可写时，就把事件分发给对应逻辑处理，不需要为每个连接单独分配线程。Redis 基于该模型，引入了 IO 多线程机制，在保持“命令执行逻辑仍为单线程”的同时，让read / write / encode / decode这些耗时的 IO 运行能够被多个线程并行执行，从而提升整体吞吐性能。

3.1 Reactor 模型流程

Redis 的网络 IO 处理流程如下：

1. Acceptor 阶段
   当客户端发起连接时，acceptor 负责建立连接，并将新连接交给 Reactor 管理。

2. Reactor 主循环
   Reactor（主线程）依据 IO 多路复用同时监听多个客户端的 socket：

   • 如果检测到可读事件，说明客户端发送了数据；
   • 如果检测到可写事件通过，说明能够往客户端发送响应。

3. Dispatch 分发阶段
   Reactor 将这些已就绪的事件派发（dispatch）给合适的处理流程。
   对于 Redis 而言，就是按照顺序执行：

   • read：读取客户端请求数据；
   • decode：解析 Redis 协议（RESP）；
   • compute：执行命令（由主线程完成）；
   • encode：对执行结果进行协议封装；
   • send：将结果发送给客户端。

每个客户端请求经过统一的 Reactor 调度后，依次结束读、解码、计算、编码和发送。

3.2 为什么应该 IO 多线程

在传统单线程模型中，Redis会对客户端请求进行完全串行处理：先读取第一个客户端的请求，接着依次执行协议解析、命令执行、结果编码，最后发送响应，之后才会处理下一个客户端。当多个客户端几乎同时发起请求时，read（读取请求数据）、send（发送响应）等IO操作只能排队串行执行，很容易因IO耗时成为性能瓶颈，限制整体处理效率。

尤其是在以下两种情况下，单线程 IO 的效率非常低：

1. 客户端发送大量数据（写入大数据）

   • Redis 得从 socket 中拷贝大量数据到用户态；
   • 协议解析（decode）需要 CPU；
   • 整个读过程是耗时且阻塞的。

2. 客户端读取大量数据（大 key 读取）

   • Redis 需要将大量资料从用户态拷贝到内核；
   • 编码（encode）和发送（send）过程同样是 CPU 密集 + IO 密集；
   • 单线程逐一发送时，其他客户端会被阻塞。

因此，Redis 在 6.0 之后引入 IO 多线程机制，让多个线程并行执行这些read / encode / send阶段，极大地提升了带宽利用率和并发性能。

3.3 多线程下的执行方式

假设现在有三个客户端同时向 Redis 发送命令请求。

在默认情况下，Redis 是单线程执行的。 主线程依次处理每个客户端的请求，流程大致是：read → decode → compute → encode → send。也就是说，Redis 先从第一个客户端读取命令并解析，然后执行命令逻辑、生成结果并返回响应； 接着再处理第二个客户端、第三个客户端。这意味着在任意时刻，只有一个请求在被完整处理，其余请求都在等待。

开启 IO 多线程后，Redis 把read、decode、encode部分并行化，而命令执行compute仍由主线程串行完成。

具体过程是这样的：

1. 主线程收集请求
   发现三个客户端的 socket 可读后，将它们放入全局队列。

2. 分发任务
   主线程把这三个请求分配给不同的 IO 线程队列，比如：3 个客户端的请求分别被放入 io_threads_list[0]、io_threads_list[1]、io_threads_list[2]。

3. 多线程并行读取
   各个 IO 线程（包括主线程自身）并行执行 read + decode，从网络中读取数据并解析命令。解析搞定后，每个线程将命令对象交回主线程等待执行。

4. 主线程执行命令
   所有请求解析完后，主线程统一串行执行三条命令逻辑，保证命令执行顺序和一致性。

5. 多线程并行发送响应
   命令执行完后，主线程再将结果分发给 IO 线程，IO 线程并行执行 encode + send，将响应写回客户端。

6. 主线程等待同步
   等所有线程发送完结果后，主线程进入下一轮事件循环。

图中结构说明：

• 上方的 server.clients_pending_*
  表示主线程收集到的所有“待处理客户端请求”，是一个全局任务队列。
• 下方的多个 io_threads_list[i]
  表示多个 I/O 线程，每个线程都有自己独立的任务队列。
• 左边的 io_threads_list[0]
  特殊：对应主线程。

每个线程（包括主线程）都拥有一个独立的任务队列，主线程负责分发任务与同步等待。

3.4 多线程启用

Redis 默认不开启 IO 多线程。只有在满足以下条件时才有意义：

• 多个客户端同时活跃连接；
• 网络 IO 成为性能瓶颈；
• 在 redis.conf 配置文件中显式启用：

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

由于 IO 阶段仅涉及材料的读取与发送（不修改共享数据结构），因此不必须额外的加锁逻辑。 主线程在执行命令时，所有 IO 线程都处于等待状态，避免了竞争条件。