Redis到底能不能真支持多线程，还是只是个突破瓶颈的尝试？

关于Redis到底能不能真支持多线程，还是只是个突破瓶颈的尝试？这个问题，答案其实有点“既是，也不是”的味道，我们不能简单地说它“是”多线程，也不能说它“不是”，更准确的说法是：Redis的核心数据处理逻辑依然是单线程的，但它为了突破性能瓶颈，在特定的、可以并行化的地方引入了多线程。

要理解这一点，我们得从Redis的“初心”说起，根据Redis之父Salvatore Sanfilippo（网名antirez）的设计理念，他最初选择单线程架构主要是为了简单、高效和稳定。（来源：antirez的博客《Redis宣言》）单线程避免了多线程环境中令人头疼的锁竞争、上下文切换和线程同步等复杂问题，这意味着，所有客户端的命令都会在一个队列里排队，由这一个主线程按顺序执行，这样做的好处非常明显：数据操作是绝对原子性的，你完全不用担心两个命令同时修改一个数据会出问题，因为根本不可能“，这种简单性使得Redis的代码非常健壮,也易于开发和维护。

随着网络硬件的发展，特别是万兆网卡甚至更高速网络的普及，瓶颈出现了，对于一个单线程的Redis来说，即使它的内存读写速度极快（纳秒级别），但当海量网络数据包涌来时，读取客户端请求、解析协议（IO操作）以及将处理结果写回网络 这个过程，却成了最大的拖累，这个主线程不得不花大量时间在IO上，而不是它最擅长的数据处理上，这就好比一个超级厨师炒菜速度飞快，但只有一个服务员负责点菜、传菜，结果厨师大部分时间都在等服务员。（来源：基于对Redis网络模型的理解）

正是在这种背景下，Redis从6.0版本开始，做出了一个重要的改变：引入了多线程IO，这里的关键词是“IO多线程”，而不是“数据处理多线程”，这意味着，读取请求、解析协议和写回结果这些IO任务，可以被分配给多个额外的IO线程去并行处理。所有读取出来的命令，最终还是会排队送回给那个唯一的主线程去顺序执行，执行完毕后,主线程再把结果交给IO线程组去写回给客户端。

你可以把Redis 6.0之后的多线程理解为一个“前台多线程，后台单线程”的模型，前台的服务员（IO线程）从原来的一人变成了一个团队，他们可以同时接待很多客人（客户端），记录下他们点的菜（解析命令），然后把菜单整齐地排好队，交给后厨唯一的超级厨师（主线程），厨师按照顺序飞快地炒好每一道菜（执行命令）,再由前台的服务员团队把菜端给客人。

这算不算是“真支持多线程”呢？从严格意义上讲，它不是，因为最核心、最消耗CPU的数据结构操作（比如增删改查、计算等）依然没有被多线程化，还是单线程的，它的多线程只是一种“辅助”，目的是为了把主线程从繁重的网络IO负担中解放出来，让它能更专注于数据处理，从而整体上提升吞吐量，突破网络IO这个瓶颈，这确实是一种“突破瓶颈的尝试”，而且被证明是非常成功的尝试，根据官方测试和很多用户的反馈，在IO密集的场景下，开启多线程IO后，Redis的性能可以有倍数级的提升。（来源：Redis 6.0 Release Notes）

在Redis的后续版本中，还尝试了在另一些“边缘”但耗时的任务上使用多线程，比如在后台异步删除大Key（UNLINK命令）、持久化生成RDB快照文件等，这些任务如果放在主线程做，会严重阻塞正常的命令处理，把它们丢到额外的线程里异步执行，也是典型的利用多线程解决瓶颈问题的思路,但同样不改变核心数据操作的单线程本质。

Redis的“多线程”是一个精心设计的、有明确范围的优化，它没有颠覆其单线程内核的简单性和数据安全性，而是像一个精明的管理者，把那些可以并行且不涉及数据竞争风险的脏活、累活（网络IO、大文件删除）外包给了一个团队，从而让核心主力（主线程）发挥出最大的效能，它既不是传统意义上的多线程数据库，也不是一个简单的尝试，而是一个在保持核心优势前提下，针对现代硬件瓶颈的高效、务实的解决方案。