Redis 为什么是单线程？为什么这么快？

洛水晗

273人浏览 · 2026-05-21 19:40:56

洛水晗 · 2026-05-21 19:40:56 发布

一、澄清：Redis 真的是单线程吗？

+------------------------+  主线程（命令处理 + 网络监听）
| redis-server           |  <- 单线程部分
+------------------------+

+------------------------+  后台线程
| bio-close-file         |  <- 异步关闭大文件
| bio-aof-fsync          |  <- 异步 AOF 刷盘
| bio-lazy-free          |  <- 异步删除大内存
| jemalloc-bg-threads    |  <- jemalloc 后台线程
+------------------------+

+------------------------+  IO 线程（可选）
| io-threads             |  <- 辅助 IO 处理
+------------------------+

真正的单线程： redis-server 主线程负责所有命令处理和网络事件监听。

所以准确说法是：Redis 的命令处理和网络 IO 在主线程中执行，其他耗时操作异步化到后台线程。

二、为什么采用单线程？

2.1 核心原因：操作是内存密集型而非 CPU 密集型

Redis 是内存数据库，操作的是内存数据：

内存操作的速度：纳秒级
CPU 不是瓶颈，瓶颈在 IO

多线程的优势是利用多核 CPU 并行处理，但 Redis 的操作不涉及复杂计算，多线程带来的收益有限。

2.2 多线程的问题：锁的复杂性

Redis 支持多种对象类型：

对象类型	数据结构实现
string	int / embstr / raw
list	ziplist / linkedlist
hash	ziplist / dict
set	intset / dict
zset	ziplist / skiplist + dict

每个对象类型有多种底层实现，如果采用多线程：

需要对每个对象加锁
锁的粒度难以控制
加锁解锁本身有开销

锁粒度问题： 临界资源的操作需要尽量短的持有时间，否则影响并发性能。

2.3 多线程的问题：频繁上下文切换

Redis 请求量不可控，可能出现：

请求A -> 线程1 -> 休眠
请求B -> 线程2 -> 休眠
请求C -> 线程3 -> 休眠
   |
线程不断切换，争取 CPU 时间片

频繁的上下文切换会抵消多线程带来的好处，单线程反而更高效。

2.4 单线程的局限：不能有耗时操作

主线程执行：
[请求1] -> [请求2] -> [耗时操作] -> [请求3] -> ...
                               |
                           阻塞！

如果主线程中有耗时操作，后续所有请求都会被阻塞。

所以 Redis 将所有可能阻塞的操作异步化到后台线程。

三、为什么单线程这么快？

3.1 内存数据库：自身特性

数据存储在内存中，内存访问速度远高于磁盘：

内存：纳秒级访问
SSD：微秒级访问
HDD：毫秒级访问

内存操作本身已经足够快，不需要多线程并行。

3.2 高效的数据结构

每种对象类型针对不同场景选择最优数据结构：

对象类型	小数据量	大数据量	权衡点
hash	ziplist	dict	节点数 <= 512 用 ziplist
zset	ziplist	skiplist + dict	节点数 <= 128 用 ziplist
list	ziplist	linkedlist	节省空间 vs 快速插入
set	intset	dict	整数集合优化内存

核心思想：根据数据量动态选择数据结构，在时间和空间上取得平衡。

3.3 Reactor 网络模型

Redis 采用经典的多路复用 IO 模型：

                    [文件描述符就绪事件]
                              |
+----------------------------------------------------------+
|                      主线程                               |
|  [socket1] [socket2] [socket3] ... [socketN]            |
|     |          |           |                |            |
|      [IO多路复用 epoll/select]                           |
|                      |                                   |
|              [就绪事件分派]                               |
|                      |                                   |
|              [命令处理器]                                 |
+----------------------------------------------------------+

为什么快：

IO 多路复用：一个线程同时监听多条连接
非阻塞 IO：IO 操作不会阻塞主线程
事件驱动：只处理就绪的事件

3.4 异步化设计

将可能阻塞的操作全部异步化到后台线程：

操作	异步方式	说明
关闭大文件	bio-close-file	close() 需要释放 FD 资源
AOF 刷盘	bio-aof-fsync	fsync 是阻塞操作
删除大内存	bio-lazy-free	释放大块内存也是一种阻塞操作
内存分配	jemalloc-bg-threads	jemalloc 后台线程

四、Redis 做了哪些优化？

4.1 渐进式 rehash

dict 扩容采用渐进式 rehash，避免一次性拷贝大量数据：

第一阶段：两个哈希表同时存在
+----------+----------+
| 旧表     | 新表     |  (新表为空)
+----------+----------+

第二阶段：渐进迁移
+----------+----------+
| 旧表     | 新表     |  (逐个迁移)
+----------+----------+

第三阶段：迁移完成
+----------+----------+
|          | 新表     |  (旧表为空)
+----------+----------+

具体策略：

每次操作迁移一个桶
或者定时任务每次迁移 1ms
分散阻塞操作

4.2 IO 多线程（可选）

Redis 6.0 引入了 IO 多线程，可以辅助处理 IO：

主线程：负责命令处理 + 网络事件监听
IO线程：辅助处理 read/write/decode/encode

注意：命令处理仍在主线程，IO 线程只处理网络层的读写。

4.3 扩容策略：翻倍扩容

容量：64 -> 128 -> 256 -> 512 -> 1024 ...

采用翻倍扩容策略：

减少扩容次数
摊销扩容成本
空间换时间

五、面试追问 FAQ

问题	回答要点
Q: Redis 真的只有单线程吗？	不是，主线程单线程，但有 bio 后台线程处理异步任务
Q: 为什么 Redis 用单线程而不是多线程？	Redis 是内存密集型不是 CPU 密集型，多线程会带来锁和上下文切换的开销
Q: 单线程如何保证高性能？	内存操作 + IO 多路复用 + 高效数据结构 + 异步化
Q: 什么操作不能放在主线程？	耗时操作：关闭大文件、刷盘、删除大内存、扩容
Q: IO 多线程的作用是什么？	只辅助处理网络 IO（read/write/encode/decode），命令处理仍在主线程
Q: dict 渐进式 rehash 是什么？	扩容时不是一次性迁移，而是分散到每次操作中，避免阻塞

六、相关题目

题目	考察点
Redis 6.0 多线程了解吗？	IO 多线程 vs 命令处理单线程
Redis 为什么不用 B+ 树？	实现复杂度 vs 内存数据库场景
Redis 持久化会阻塞主线程吗？	AOF fsync 后台线程，RDB 是 fork 子进程
Redis 的 key 过期后内存会立即释放吗？	惰性删除 + 定时删除，不会立即释放