Redis线程封闭到底是咋回事，带你慢慢理清这门技术背后的秘密

（引用来源：Redis官方文档、Antirez（Redis创始人）的博客文章《Redis不是单线程的》、多位资深后端工程师的技术分享）

Redis线程封闭到底是咋回事，带你慢慢理清这门技术背后的秘密

很多人一提到Redis，第一反应就是：“哦，那个单线程的缓存数据库。” 这个说法流传很广，但它其实只说对了一半，甚至可以说是一个“美丽的误会”，Redis真正的核心技术点，不在于“单线程”这三个字，而在于“线程封闭”这个设计思想，今天我们就来慢慢剥开这颗洋葱,看看它里面到底藏着什么秘密。

第一层：为什么大家会误以为Redis是单线程的？

这个误会来源于Redis处理核心业务的方式，你想啊，一个Redis服务器，在同一时刻，只能处理一条来自客户端的命令，你同时让Redis执行10个操作：设置一个键、获取一个值、增加一个数字……这10个命令不能同时被Redis的核心引擎处理，它得排着队，一个接一个来，这种感觉，就像银行只有一个业务窗口，所有顾客都得排队办理,这不就是单线程的行为吗？

大家说Redis是单线程，主要是指它的网络I/O（输入输出）和键值对读写这个最核心的流程，是由一个线程来完成的，这个核心线程我们通常称之为“主线程”。

第二层：秘密揭晓——Redis早就不是纯粹的单线程了！

问题来了，如果真只有一个线程干活，那有些活儿就会变得特别慢，从而拖累整个系统，Redis的作者很早就意识到了这一点，所以悄悄地引入了多线程来处理一些“杂活”，从Redis 4.0版本开始，一些耗时的操作就被剥离出来，交给了后台的“小工”（其他线程）去处理。

最典型的例子就是惰性删除，你下令删除一个包含几百万个元素的超大集合，如果让主线程去干这个苦力活，它可能要花好几秒钟，在这几秒钟里，主线程啥也干不了，无法响应任何新的命令，这就叫“阻塞”，是高性能系统的大忌，Redis 4.0之后，当你发出删除命令时，主线程只是把要删除的键从空间里标记一下，然后就立刻返回告诉你“搞定啦！”，接着就去处理下一条命令了，而真正费劲的清理内存工作，则交给了一个专门的后台线程去慢慢做，这样，主线程就避免了被“累死”。

到了Redis 6.0，多线程的应用更进一步，这次，连网络I/O这种核心流程也部分地用上了多线程，你可以这样理解：以前，主线程既要负责从网络连接上读取客户端的请求数据（读数据），又要负责执行命令，还要负责把结果写回给客户端（写数据），Redis 6.0可以配置多个I/O线程，让它们专门负责读数据和写数据这些“跑腿”的活儿，而最核心的命令执行步骤,依然坚定地由那个唯一的主线程来完成。

现在的Redis是一个“混合体”：多线程处理I/O和后台慢操作，但单线程执行核心命令。

第三层：核心秘密——“线程封闭”的精髓到底是什么？

现在我们触及了最核心的秘密：为什么Redis要坚持让核心命令的执行保持“单线程”模式？答案就是“线程封闭”（Thread Confinement），更准确地说，是避免了“线程共享”带来的噩梦。

在多线程编程中，最头疼的问题就是“锁”，如果多个线程同时去读写同一块内存数据（比如一个键值对），为了保证数据不出错（比如一个线程在读的时候，另一个线程在修改），就必须给这块数据加锁，线程们要抢到锁才能干活，抢不到就得等着,这就带来了两个大问题：

1. 竞争开销：线程们争抢锁本身会消耗大量的CPU资源。
2. 死锁风险：如果锁的设计和使用稍有不慎，就可能出现两个线程互相等待对方释放锁，导致程序“卡死”的尴尬局面。

Redis的作者Antirez认为，对于Redis这种内存数据库，它的主要性能瓶颈是CPU吗？不完全是，更多的是内存的访问速度和网络的延迟，一个单纯的CPU指令执行起来是飞快的，但线程间为了协调而等待、抢锁所浪费的时间,可能远远超过命令本身执行的时间。

Redis采用了“线程封闭”的绝招：我把所有最重要的数据都交给一个线程来管理，这个线程拥有对这些数据的“独占权”，其他线程不许直接碰这些数据。 这就好比一个仓库，只配一个管理员，所有要存东西、取东西的人，都必须通过这个管理员，虽然看起来效率不高，但彻底避免了多人同时进仓库找东西造成的混乱、碰撞和争吵。

这样做的好处是巨大的：

• 无锁设计：因为不存在并发访问，所以根本不需要复杂的锁机制,CPU可以把所有资源都用在真正处理命令上。
• 极高的可预测性：每个命令的执行时间都是稳定的,不会因为某个命令运气不好抢不到锁而等待不确定的时间。
• 简单就是美：单线程模型使得Redis的代码实现和维护变得非常简单和稳定,bug更少。

Redis线程封闭的秘密可以这样概括：它用一个“国王”（主线程）来掌管所有核心数据和命令执行，确保王国内部的秩序和高效；同时雇佣了一批“信使”（I/O线程）和“清洁工”（后台线程）来处理外围的、耗时的杂务,避免国王被琐事缠身。

它不是一个固执的“单线程主义者”，而是一个精明的“线程封闭策略家”，它通过巧妙的职责划分，既享受了多线程处理I/O和慢操作带来的吞吐量提升，又通过核心单线程的模式，完美规避了多线程编程中最令人头疼的并发控制问题，从而达到了简单与高效的精妙平衡,这才是Redis高性能背后真正的技术智慧。