Redis 为什么快？现在还是单线程吗？

1. 引言

Redis 是互联网后端最常用的缓存与中间件之一，动辄支撑每秒几十万甚至上百万次请求。很多人在面试或技术分享时都会问同一个问题：Redis 为什么这么快？它现在还是单线程吗？

本文从内存存储、数据结构、IO 模型、事件循环、多线程演进等几个维度，把 Redis 高性能的底层原因讲清楚，并回答「单线程」这个经典话题的最新答案。

2. 快的原因之一：纯内存存储

Redis 的数据全部保存在内存中，读写不涉及磁盘 IO。

内存随机读写的延迟通常在 纳秒级（约 100ns 量级），而磁盘顺序读写是毫秒级，随机读写更慢。
相比 MySQL 等需要落盘的数据库，Redis 省去了磁盘寻道、页缓存、刷盘等开销。
即使开启持久化（RDB/AOF），也是异步或后台进行，不阻塞主流程。

一句话：内存是 Redis 快的地基。

3. 快的原因之二：高效的数据结构

Redis 不是简单地把数据塞进一个大 Map，而是针对不同场景设计了多种底层编码，在时间和空间上做了精细权衡。

数据类型	底层实现	特点
String	SDS（简单动态字符串）	常数级获取长度，避免缓冲区溢出
List	quicklist / 压缩列表	兼顾内存与读写效率
Hash	哈希表 + 压缩列表 / listpack	小对象省内存，大对象 O(1) 访问
Set	整数集合 / 哈希表	小集合用数组，省内存且快
ZSet	跳表 + 哈希表	有序且支持范围查询

其中 SDS 和跳表是 Redis 最具代表性的设计：

SDS 记录了字符串长度，STRLEN 是 O(1)，且能避免 C 字符串的拼接溢出问题。
跳表让 ZSet 的插入、删除、范围查询都接近 O(log N)，实现简单且并发友好。

4. 快的原因之三：单线程 + IO 多路复用

这是 Redis 快的最核心原因，也是「单线程」话题的由来。

4.1 为什么单线程反而快

传统多线程模型需要处理锁竞争、上下文切换、线程调度等额外开销。Redis 选择单线程处理命令，换来的是：

无锁设计，不存在死锁、竞态条件；
避免线程上下文切换的 CPU 开销；
所有命令天然串行执行，简单且可预测。

4.2 IO 多路复用

单线程要同时服务大量连接，靠的是 IO 多路复用（epoll / kqueue / select）。

Redis 用一个线程同时监听成千上万个 socket；
只有某个 socket 可读/可写时才触发事件处理；
避免了「每个连接一个线程」的阻塞模型。

整体流程如下：
#mermaid-svg-xi9t1sHVTA5c1p7W{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-xi9t1sHVTA5c1p7W .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-xi9t1sHVTA5c1p7W .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-xi9t1sHVTA5c1p7W .error-icon{fill:#552222;}#mermaid-svg-xi9t1sHVTA5c1p7W .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-xi9t1sHVTA5c1p7W .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-xi9t1sHVTA5c1p7W .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-xi9t1sHVTA5c1p7W .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-xi9t1sHVTA5c1p7W .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-xi9t1sHVTA5c1p7W .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-xi9t1sHVTA5c1p7W .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-xi9t1sHVTA5c1p7W .marker{fill:#333333;stroke:#333333;}#mermaid-svg-xi9t1sHVTA5c1p7W .marker.cross{stroke:#333333;}#mermaid-svg-xi9t1sHVTA5c1p7W svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-xi9t1sHVTA5c1p7W p{margin:0;}#mermaid-svg-xi9t1sHVTA5c1p7W .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-xi9t1sHVTA5c1p7W .cluster-label text{fill:#333;}#mermaid-svg-xi9t1sHVTA5c1p7W .cluster-label span{color:#333;}#mermaid-svg-xi9t1sHVTA5c1p7W .cluster-label span p{background-color:transparent;}#mermaid-svg-xi9t1sHVTA5c1p7W .label text,#mermaid-svg-xi9t1sHVTA5c1p7W span{fill:#333;color:#333;}#mermaid-svg-xi9t1sHVTA5c1p7W .node rect,#mermaid-svg-xi9t1sHVTA5c1p7W .node circle,#mermaid-svg-xi9t1sHVTA5c1p7W .node ellipse,#mermaid-svg-xi9t1sHVTA5c1p7W .node polygon,#mermaid-svg-xi9t1sHVTA5c1p7W .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-xi9t1sHVTA5c1p7W .rough-node .label text,#mermaid-svg-xi9t1sHVTA5c1p7W .node .label text,#mermaid-svg-xi9t1sHVTA5c1p7W .image-shape .label,#mermaid-svg-xi9t1sHVTA5c1p7W .icon-shape .label{text-anchor:middle;}#mermaid-svg-xi9t1sHVTA5c1p7W .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-xi9t1sHVTA5c1p7W .rough-node .label,#mermaid-svg-xi9t1sHVTA5c1p7W .node .label,#mermaid-svg-xi9t1sHVTA5c1p7W .image-shape .label,#mermaid-svg-xi9t1sHVTA5c1p7W .icon-shape .label{text-align:center;}#mermaid-svg-xi9t1sHVTA5c1p7W .node.clickable{cursor:pointer;}#mermaid-svg-xi9t1sHVTA5c1p7W .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-xi9t1sHVTA5c1p7W .arrowheadPath{fill:#333333;}#mermaid-svg-xi9t1sHVTA5c1p7W .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-xi9t1sHVTA5c1p7W .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-xi9t1sHVTA5c1p7W .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-xi9t1sHVTA5c1p7W .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-xi9t1sHVTA5c1p7W .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-xi9t1sHVTA5c1p7W .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-xi9t1sHVTA5c1p7W .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-xi9t1sHVTA5c1p7W .cluster text{fill:#333;}#mermaid-svg-xi9t1sHVTA5c1p7W .cluster span{color:#333;}#mermaid-svg-xi9t1sHVTA5c1p7W div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-xi9t1sHVTA5c1p7W .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-xi9t1sHVTA5c1p7W rect.text{fill:none;stroke-width:0;}#mermaid-svg-xi9t1sHVTA5c1p7W .icon-shape,#mermaid-svg-xi9t1sHVTA5c1p7W .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-xi9t1sHVTA5c1p7W .icon-shape p,#mermaid-svg-xi9t1sHVTA5c1p7W .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-xi9t1sHVTA5c1p7W .icon-shape .label rect,#mermaid-svg-xi9t1sHVTA5c1p7W .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-xi9t1sHVTA5c1p7W .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-xi9t1sHVTA5c1p7W .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-xi9t1sHVTA5c1p7W :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 是
否
客户端连接
epoll 监听事件
事件就绪?
读取命令
单线程执行命令
写回响应

4.3 单线程的瓶颈

单线程虽然简单高效，但也有天花板：

单个命令执行过慢（如 KEYS *、大 SORT）会阻塞所有请求；
CPU 多核利用率不足；
大 key 的序列化/反序列化耗时。

因此 Redis 官方一直在做「把耗时操作移出主线程」的优化。

5. 现在还是单线程吗？------ 答案：不完全是

这是很多人容易混淆的点。准确说法是：

Redis 的命令执行核心仍然是单线程，但 Redis 早已不是「整个进程只有一个线程」。

5.1 6.0 引入多线程 IO

Redis 6.0 开始支持 IO 多线程，用于处理网络读写：

主线程仍然负责执行命令（保持无锁、串行）；
多个 IO 线程分担 socket 读、写、解析 等网络 IO 工作；
命令执行阶段依然是单线程，因此数据一致性不受影响。

这样既保留了单线程执行命令的简单性，又提升了多核 CPU 的利用率，尤其在高并发网络 IO 场景下收益明显。

5.2 其它后台线程

即便在 6.0 之前，Redis 也有多个后台线程/进程在干活：

持久化：RDB 快照、AOF 重写由子进程或后台线程完成；
异步删除 ：UNLINK、FLUSHALL ASYNC 等把大 key 释放放到后台线程；
集群通信：部分版本中集群总线等也有独立线程。

所以更严谨的结论是：

执行命令：单线程（核心）
网络 IO：多线程（6.0+ 可选开启）
后台任务：多线程/多进程

6. 如何配置多线程 IO

Redis 6.0+ 默认关闭 IO 多线程，需要手动开启：

bash 复制代码

# redis.conf
io-threads 4
io-threads-do-reads yes

注意事项：

io-threads 建议不超过 CPU 核数；
只有网络 IO 是瓶颈时才值得开启；
命令执行仍是单线程，别指望它提升单条命令的吞吐。

7. 总结

回到最初的问题：Redis 为什么快？

纯内存存储，读写延迟极低；
精心设计的数据结构，时间与空间兼顾；
单线程执行命令 + IO 多路复用，无锁、无上下文切换；
多线程 IO 与后台任务，进一步榨干多核性能。

现在还是单线程吗？

命令执行核心依然是单线程；
但网络 IO 已支持多线程（6.0+），后台任务也早已多线程化；
所以准确说法是：「单线程执行命令」+「多线程 IO 与后台任务」。

理解 Redis 的快，不能只背「单线程」三个字，而要看到它在内存、数据结构、事件模型上的整体设计取舍。