单线程与 IO 模型

2.1单线程到底指什么

「单线程」精确指的是：命令的执行在单一线程里串行完成；但 Redis 进程并非只有这一个线程，后台另有子进程与多个辅助线程在干活。

这句话的准确含义是：对客户端命令的「执行」这一段，由单一线程串行完成——同一时刻只有一条命令在改数据，下一条必须等当前这条返回。这根线程通常称为主线程（main thread），它跑的是事件循环（2.2 详述）。

但「命令执行单线程」不等于「进程只有一个线程」。一个真实的 Redis 进程里，至少还有下面这些不在主线程上的活：

• bgsave 子进程：BGSAVE / AOF 重写时 fork（创建一个内存几乎一致的子进程）出独立进程做磁盘 dump，主线程继续服务请求。详见 03。
• AOF 刷盘线程：appendfsync everysec 模式下，fsync（把内核缓冲真正落盘）交给一个后台线程（bio，background I/O），避免磁盘卡顿堵住主线程。
• lazyfree 线程：lazyfree（惰性释放，把大对象的内存回收挪到后台）专门的线程异步释放大对象占的内存，避免一次 free 巨型结构卡住主线程。UNLINK 就靠它（2.5 详述）。
• io-threads：Redis 6.0 起可选的 IO 线程，并行做 socket 读写与协议解析（2.6 详述）。

2.2IO 多路复用 + 事件循环

一根线程靠 IO 多路复用同时监听上万个 socket 的就绪事件，谁就绪就处理谁——这是「单线程还能扛高并发」的机制。

Redis 自己实现了一个极薄的事件循环库，源码里叫 ae（A simple event-driven library），对应文件 ae.c。它在底层封装了操作系统提供的 IO 多路复用机制：Linux 上是 epoll、BSD / macOS 上是 kqueue，都没有时退回 select。这种「一个事件循环线程 + 多路复用 + 事件回调」的结构，就是经典的 reactor 模式（反应堆模式：事件到达后分发给对应处理器）。

关键在于 epoll 这类机制让一根线程同时盯住上万个 socket：线程把所有客户端连接注册进 epoll，然后阻塞在 epoll_wait 上；一旦其中任意若干个 socket 变为「可读」（客户端发来了命令）或「可写」（可以回数据了），内核就把这批就绪的 socket 一次性返回。线程于是只对就绪的连接做事，从不为某一个连接空等。一轮处理流程是：

1. 读就绪：epoll 报告某 socket 可读，主线程从内核读出字节。
2. 解析命令：按 RESP（Redis 序列化协议）把字节解析成一条命令。
3. 执行：在主线程上串行执行这条命令，读写内存数据结构。
4. 写回：把结果写进输出缓冲，socket 可写时发回客户端。

2.3为什么单线程反而快

Redis 的瓶颈是内存与网络，不是 CPU；单线程省掉了多线程的全部协调成本——锁、上下文切换、缓存行竞争——反而比多线程更快。

把「快」归因到一句「内存快」是不够的。准确的因果链分三步：

• 瓶颈不在 CPU：Redis 的绝大多数命令是内存里的 O(1) / O(logN) 操作，单条命令耗时常在微秒级。真正的限制是内存带宽和网络往返，而不是 CPU 算力。CPU 既然不是瓶颈，多线程能榨出的并行算力就基本用不上。
• 多线程的代价却全要付：一旦多线程并发改同一份内存数据，就必须加锁保护，于是带来锁争用、线程上下文切换、以及 CPU 缓存行在核间来回失效（false sharing，伪共享）。这些协调成本在高频小操作下占比极高。
• 单线程把这些成本全省了：没有锁、没有上下文切换、没有缓存行竞争。一根线程闷头跑，CPU 缓存命中率高、指令流水线不被打断。省下的协调成本，超过了「用不上的那点并行算力」。

2.4命令天然原子（核心推论）

单线程串行 → 每条命令执行时不可能被另一条命令打断 → 这正是 INCR、SETNX、分布式锁、限流令牌桶能成立的根基。

推导只有一步，但要看清每个环节：命令执行是单线程串行的 → 同一时刻只有一条命令在改数据 → 一条命令一旦开始执行，在它返回之前，没有任何别的命令能插进来改同一份数据 → 因此每条 Redis 命令的执行天然是原子的，不需要任何锁。注意这里的原子性来自「串行执行」这个结构本身，是免费的——不是 Redis 额外加了锁机制实现的。

这条「天然原子」直接撑起了一批关键能力：

• INCR / DECR / INCRBY：「读—加—写」三步在一条命令内完成，不可被打断，所以并发计数器永不丢更新。
• SETNX 与 SET k v NX PX 30000：「不存在才设置」+「设过期」在一条命令里原子完成——这是分布式锁的根基（详见 05）。注意要用单条 SET ... NX PX，而非 SETNX 后再 EXPIRE 两条命令，否则中间会留下没有过期时间的窗口。
• Lua 脚本 / EVAL：整段脚本作为一个整体在主线程上执行，期间不穿插其他命令。限流令牌桶、库存扣减这类「多步骤要么全做要么全不做」的逻辑，靠它一次原子完成（详见 06）。

2.5大 key 为什么阻塞整个实例

一条 O(N) 命令占住唯一的执行线程期间，其余所有客户端的请求只能在队列里干等——慢的不只是这一条命令，是整个实例。

把 2.3 的「快」反过来看就是这一节。单线程串行意味着只有一根线程在执行命令——这在命令都是微秒级时是优点，但一旦某条命令是 O(N) 且 N 很大，它就会长时间霸占这根唯一的线程，排在它后面的所有请求（哪怕只是一个 GET）都得等它执行完。典型的「大 key 操作」包括：

• HGETALL 一个百万字段的大 hash——一次性遍历并序列化全部字段。
• 一次性 DEL 一个百万元素的大 key——释放上百万个内存对象，全在主线程上同步完成。
• 对大集合做 SMEMBERS、对大 ZSet 做无界 ZRANGE 0 -1、用 KEYS * 扫全库。

这里有个反直觉的点：DEL 一个大 key 也是 O(N) 的。删除不是「把指针一抹」那么简单——一个百万元素的集合，要逐个释放这百万个元素对象的内存，这个 free 的总量正比于元素个数，全程占着主线程。

Redis 4.0 为此引入了 UNLINK，把删除拆成两段：

• 主线程只做 O(1) 解链：把这个 key 从键空间里摘掉，立刻返回。对客户端来说，key 瞬间就不可见了。
• 后台 lazyfree 线程释放内存：真正耗时的「逐个 free 百万对象」挪到后台线程异步做，不占主线程。

同样的惰性释放也能让 DEL 自动享受到：把 lazyfree-lazy-user-del 配成 yes，普通 DEL 在内部就按 UNLINK 的方式走后台释放。相关的还有 lazyfree-lazy-expire（过期删除走惰性）、lazyfree-lazy-eviction（淘汰走惰性）、lazyfree-lazy-server-del（被覆盖的旧值走惰性），默认多为关闭，生产环境常建议打开。

2.6多线程的演进

io-threads（6.0）只并行 socket 读写与协议解析，命令执行仍单线程；Redis 8 / Valkey 8 让主线程与 IO 线程并发——「单线程」如今特指命令执行这一段。

当连接数和吞吐很高时，瓶颈会从「执行」转移到「在内核和用户态之间搬运网络字节、把字节解析成命令」——这部分是 CPU 密集且可以并行的。于是 Redis 把这一段逐步多线程化，但守住一条红线：命令执行始终单线程。三个阶段：

• Redis 6.0 · io-threads：引入可配置的 IO 线程（io-threads 参数），把socket 读写和 RESP 协议解析分给多个 IO 线程并行做；但命令执行仍由主线程一条条串行完成。模型是「IO 多线程，执行单线程」。
• Redis 8 / Valkey 8 · 并发 IO：进一步让主线程与 IO 线程并发工作（而非旧版那种「主线程派活后干等 IO 线程收工」的同步切换），把多核利用率再推高一截。Valkey 8 官方实测，单实例吞吐从约 360K RPS 提升到约 1.19M RPS（依硬件与负载而定）。
• 不变的内核：无论哪个阶段，改内存数据结构的那一步永远在单一线程上串行。所以 2.4 的「命令天然原子」在所有版本上都成立——这也是它能被当作分布式锁、限流根基的前提。