Redis 之所以被称为 伪多线程，主要是因为 Redis 在 6.0 版本 之前是 单线程 模型，而在 6.0 版本之后 引入了 多线程 I/O 模型，但仍然保持了核心数据操作的 单线程 特性。

这种设计使得 Redis 在使用多线程进行网络 I/O 的同时，核心逻辑处理仍然是单线程，外界通常称这种模型为 伪多线程

在 Redis 6.0 之前，Redis 的所有操作，包括 网络 I/O 和 数据处理，都是在单个线程中完成的。这种单线程设计的优点包括：

• 简化并发控制：避免了多线程并发访问带来的加锁和线程安全问题，保证了数据一致性。

• 性能优越：单线程模型结合高效的 事件循环（基于 epoll、kqueue 等 I/O 多路复用机制），在大多数场景下已经足够高效，尤其适合 CPU 不是瓶颈的场景。

但缺点是：

• 网络 I/O 可能成为瓶颈：单线程处理所有网络请求，导致 I/O 的等待时间成为性能的主要瓶颈。

• 无法充分利用多核 CPU：Redis 无法同时利用多个 CPU 核心处理数据。

Redis 6.0 引入了 多线程模型，但它的多线程仅限于 网络 I/O 读取和写入，核心的数据操作（例如读写键值对）仍然是单线程完成的。具体过程如下：

多线程处理网络 I/O：

单线程处理核心数据逻辑：

这种设计的优点是：

• 在网络 I/O 密集的场景下，可以充分利用多核 CPU，提升网络吞吐量。

• 数据操作仍然是单线程执行，避免了数据加锁和线程同步的复杂性。

缺点：

• 核心的数据操作依然无法并行，计算密集型任务无法利用多线程提升性能。

Redis 被称为 伪多线程 的原因在于：

• 虽然引入了 多线程，但 Redis 的多线程仅用于 网络 I/O 操作，而核心的 数据读写和逻辑处理 仍然是单线程的。

• 这种设计让 Redis 既能提升网络性能，又能保持数据操作的简单性和安全性。

因此：

• Redis 是 真正的多线程（在网络 I/O 层面）。

• 但 Redis 的核心逻辑仍然是 单线程，无法实现数据操作的并发处理，因而被称为 伪多线程。

  
  

Redis 采用这种“伪多线程”设计，主要是为了在提升性能的同时保持简单性和线程安全，避免加锁带来的复杂性开销。

今天的内容就分享到这儿，喜欢的朋友可以关注，点赞。有什么不足的地方欢迎留言指出，您的关注是我前进的动力！

END

扫码关注

一起积累后端知识

不积跬步，无以至千里

不积小流，无以成江海