Redis 单线程是玄学？不，是一道精明的取舍题

「单线程」这个答案，该更新版本号了快的两个底牌：内存 + 会偷懒的 I/Oepoll：从挨家挨户敲门，到有人按铃再起床Reactor：一个前台，加一组专员单线程时代：三个角色挤一间办公室6.0 多线程：搬货外包，盖章还得老板亲自写到最后

「Redis 是单线程的」——这大概是程序员面试里出现频率最高的八股之一。很多人张口就来，可面试官顺势追问一句「那 6.0 之后呢？」，场面立马安静。

其实这句话得加个精确的限定词：Redis 在处理命令时是单线程的。从网络读取请求、解析命令、执行命令、到返回响应，这一整条路径由一个主线程串行完成。但要说 Redis 整个进程里只有一个线程，那就冤枉它了——持久化、异步删除大 key、AOF 重写这些脏活累活，从一开始就是后台线程在偷偷干。

而 6.0 引入的「多线程」，也不是把命令执行改成多线程，只是把网络 I/O 的读写外包给了几个帮手。命令怎么执行、数据怎么改，依然牢牢攥在主线程手里。想搞明白这套设计的来龙去脉，得从 epoll 和 Reactor 这两块地基讲起。

Redis 快，先说人尽皆知的那一半：纯内存操作。数据全在内存里，读写延迟是纳秒到微秒级，跟磁盘 I/O 比直接赢在起跑线。

另一半就没那么出名了：高效的 I/O 模型。在 Linux 上，Redis 用的是 epoll + Reactor 组合——epoll 负责管着成千上万的网络连接，Reactor 负责把事件分发给对应的处理逻辑。两者配合，一个线程也能同时伺候上万个客户端。下面拆开讲。

在 Linux 里「万物皆文件」，网络连接（socket）也不例外。epoll 干的事，本质上就是帮你管一大堆文件描述符（fd），谁有数据了就告诉你。它内部靠两个数据结构撑场子：一棵红黑树存所有被监控的 fd（增删查都是 O(log n)），一条就绪链表存已经有事的 fd。

对外就三个系统调用，三步走：

epoll 最妙的地方，是它和前辈 select 的本质区别：就绪队列是「被动填充」的。select 是每次调用都把传进来的 fd 挨个问一遍「有数据吗」，一次调用遍历一次，fd 一多就慢。而 epoll 只要在注册之后，某个 fd 一满足条件，内核就通过网卡中断的回调主动把它放进就绪队列——你调 epoll_wait 时，只是把现成的结果取走，有人按铃你再起床，不用挨家挨户敲门。

三家的差距，一张表看明白：

连接数一多，select/poll 反复拷贝、反复遍历的开销就压不住了，这也是高并发场景 epoll 一统江湖的原因。

光有 epoll 还不够，得有人决定「事件来了谁来办」，这就是Reactor 模式：一个分发器 + 一堆处理器。网络事件就两类——新客户端连进来是连接事件，交给 Acceptor 完成初始化；已有连接上的收发数据是读写事件，交给对应的 Handler 处理。

根据线程怎么安排，Reactor 有两个常见变种：

• 变种一：Reactor 主线程只管接客（监听连接），把初始化好的连接分给其他线程，各线程监听自己那摊连接的读写事件；
• 变种二：IO 线程池——多个 IO 线程并行做数据读写和命令解析，但命令执行仍由主线程完成。这正是 Redis 6.0 采用的方案

在 6.0 之前，Reactor、Acceptor、Handler 这三个角色在逻辑上分得清清楚楚，物理上却是同一个线程。主线程一个循环跑到底：调 epoll_wait 拿到就绪的 fd——可读就读数据、解析、执行命令；可写就把响应写回去；有新连接就完成初始化、接着监听它的读写事件。

这么干的好处实在诱人：没有线程间通信，没有锁，没有上下文切换，所有命令天然串行，原子性白送。那 Redis 为什么敢这么设计？官方给过答案，归纳起来三条：

• CPU 不是瓶颈：操作全在内存里，CPU 根本跑不满，官方原话是瓶颈最可能是内存大小或网络带宽，而不是 CPU；
• 躲开锁的泥潭：Redis 里不只有简单 kv，还有 list、hash、跳表这些复杂结构，多线程一上就得处处加锁，同步开销吃掉收益；
• 代码简单好调试：逻辑是一条直线，出了问题顺着查就行，不用跟并发边界情况斗智斗勇。

反例就是 Memcached。它选了多线程路线，多个 worker 并行处理请求，代价是锁管够：一个普通 get/set 要过两层锁——细粒度的 item_locks（八核机器上约8192 把）和一把全局 cache_lock，全局锁让它在多核上的扩展性始终受限，后续版本打了不少补丁也没根除。一个是偏「简洁」的取舍，一个是偏「并行」的取舍，没有绝对的对错，只有代价不同。

单线程的好日子是被网络硬件打破的。万兆网卡普及、连接数暴涨之后，一个线程又收发数据又执行命令，渐渐忙不过来：连接数超过 8 万时，吞吐曲线趋于平缓，P99 延迟明显上翘。机器明明有八核十六核，网络 I/O 却只能占一个核——这才有了 6.0 的多线程。

记住分工：IO 线程只负责从 socket 读数据、解析协议、把响应写回去；接收连接、分发事件、执行命令，全部还是主线程的活。相当于把「搬货」外包出去，「盖章」必须老板亲自来，数据一致性一点没破坏。

效果立竿见影。Redis 作者 antirez 在 RedisConf 2019 上分享过：多线程 I/O 下 GET/SET 性能几乎翻倍。阿里云开发者社区的实测（16C + 32GB CentOS 7）更细：

实测里还藏着一个容易踩的坑：如果测试工具 redis-benchmark 自己不加 --threads 参数，多线程的提升几乎看不出来——因为瓶颈跑到了客户端身上。做性能测试时客户端和服务端都得盯，否则很容易得出错误结论。开启方式就是在配置里显式设置：

要注意，多线程模式默认是关闭的。业界的普遍看法也很务实：单线程模式已经能满足绝大多数场景，io-threads 更像是留给极端高并发场景的一个可选项，而不是开箱必开的开关。

把整条线串起来：epoll 管住了万千连接，Reactor 分好了工，单线程时代三个角色挤在一间办公室里，用极致简洁换来了无锁、无切换的执行效率；6.0 把网络 I/O 剥出去，让主线程专心执行命令，在不破坏数据一致性的前提下吃到了多核红利。

这背后的逻辑其实朴素得可爱：哪里是瓶颈，就优化哪里；不是瓶颈的地方，保持不动。单线程时代 CPU 不忙，所以单线程是最优解；等网络 I/O 成了短板，就把 I/O 分出去；命令执行始终不是瓶颈，所以它始终单线程。看懂了这笔账，下次再有人拿「单线程还是多线程」给你贴标签，你就能反问一句：先说说瓶颈在哪。

你的项目开过 io-threads 吗？有没有被 Redis 性能问题按在地上摩擦过？评论区聊聊你踩过的坑～