红色梦想里聊聊Redis到底是怎么用多线程的，线程模式那些事儿

（引用来源：Redis官方文档、Redis核心开发者及Antirez的博文、相关技术社区讨论如Redis Labs博客）

说起Redis，很多人第一反应就是“快”，而且都知道它以前是单线程的，但现在情况有点变化了，Redis也开始用上多线程了，咱们就在这红色梦想的氛围里，轻松聊聊Redis和线程的那些事儿,把它到底怎么用多线程的给捋清楚。

老黄历：为啥一开始选择单线程？

Redis的创始人Antirez在设计Redis的时候，选择单线程模型是有深刻考虑的，绝对不是技术落后，那时候，多线程编程已经挺成熟了，但他为啥不用呢？核心原因就一个字：省心。

1. 避免复杂的锁： 多线程最大的麻烦就是共享数据，多个线程同时要改一个数据，就得加锁保护，不然就乱套了，加锁解锁本身有开销，更头疼的是，如果设计不好，很容易出现死锁（几个线程互相等着，谁也动不了）或者锁竞争（线程们挤破头抢一把锁），反而让性能下降，Antirez觉得，为了这点性能提升，把系统搞得那么复杂，不值得，单线程就没这个烦恼，所有操作排着队一个一个来，天然就是线程安全的,代码简单可靠。
2. CPU不是瓶颈： Redis的快，主要不是靠CPU算得快，而是因为数据都在内存里操作，它的性能瓶颈往往在网络输入输出（I/O）和内存访问速度上，而不是CPU的计算能力，即使用一个CPU核心，只要内存够大、网络够快，Redis就能飞起来，用一个线程专心处理,反而效率更高。
3. 简单就是美： 单线程模型让Redis的代码非常简洁、可预测，容易维护和调试，这对于一个核心数据库系统来说，是巨大的优势,保证了稳定性和可维护性。

在很长一段时间里，Redis的核心工作线程就只有一个，它像个勤劳的调度员，处理所有客户端的命令请求、数据读写等。

新篇章：Redis是怎么引入多线程的？

时代在变，硬件也在变，网络速度越来越快，千兆万兆网卡都普及了，这时候，光是读写网络数据（I/O）这个活儿，对一个单线程来说就有点重了，当有大量客户端连接时，那个唯一的线程可能把大量时间花在读取客户端请求数据和写回结果数据上,反而没多少时间真正处理命令了。

从Redis 6.0版本开始，它小心翼翼地引入了多线程，但注意,这个多线程和很多人想的不一样。

（引用来源：Redis 6.0 Release Notes 和 Antirez的博文解释）

Redis 6.0引入的多线程，主要用来处理网络I/O这种耗时的操作，而不是用来同时执行命令的，可以把这理解成“I/O多线程”,核心逻辑还是单线程。

具体是怎么分工的呢？

1. 主线程（还是那个核心）： 它依然是绝对的主角，负责任务的调度和命令的执行，所有数据结构的增删改查（比如设置一个键值对、从列表里弹出元素等）仍然由它一个人串行完成，这完美继承了单线程时代无锁操作的优点,保证了原子性和一致性。
2. I/O工作线程（新来的帮手）： 来了几个专门负责“搬砖”的帮手线程，它们的任务是：
   • 读数据： 当客户端发来请求数据包时，由这些I/O线程负责从网络套接字里把数据读出来，解析成一个个命令,然后放进一个队列里排队。
   • 写数据： 当主线程处理完一个命令，生成结果后，它不自己忙着把结果写回网络，而是把结果也放到另一个队列里，I/O线程会从队列里取出结果,负责把它们写回给对应的客户端。

这样一来，主线程就从繁重的网络读写劳动中解放出来了，它只需要专注于自己最擅长的“计算”部分——执行命令，这种模式大大提升了在高并发、大数据量网络传输场景下的性能，特别是在需要返回大量数据（比如执行一个keys *命令，虽然这命令生产环境不推荐用）或者有很多客户端连接的时候。

重要提醒：别搞混了“后台线程”

除了I/O多线程，Redis其实早就有一些“后台线程”在默默干活了，很多人会把这个和6.0的多线程搞混。

（引用来源：Redis持久化文档）

这些后台线程是负责一些慢速的、可以异步执行的任务，最典型的就是持久化。

• AOF fsync： 当Redis通过AOF日志做持久化时，可以配置为每秒或每个命令都同步到磁盘，这个把日志数据刷到磁盘（fsync）的操作比较慢，如果让主线程来做，它会卡住等磁盘响应，所以Redis会用一个专门的后台线程去执行这个刷盘操作,主线程继续愉快地处理客户端请求。
• 懒惰释放（Lazy Free）： 当你删除一个非常大的键（比如一个包含几百万元素的集合）时，释放内存可能需要很长时间，如果让主线程干，又会阻塞,所以Redis也可以配置成让后台线程来慢慢释放这块内存。

这些后台线程和6.0的I/O工作线程是两码事，它们负责的是不同的特定任务,目的都是为了不阻塞主线程。

现在的Redis，可以看作是一个“主从协作”的线程模式：

• 核心大脑（主线程）： 单线程，坚决不动摇,保证命令执行的原子性和简单性。
• 手脚（I/O工作线程）： 多线程，负责网络数据的读写这类“体力活”,让大脑更高效。
• 后勤部门（后台线程）： 多线程，负责持久化刷盘、大键删除等慢速后台任务,不打扰核心业务。

说Redis变成多线程了，是对的，但更准确的说法是，它用多线程来辅助单线程，取长补短，目的是为了在保持核心简洁性的同时，更好地利用现代硬件资源，应对更高的性能需求，它的“快”的根基,依然深深扎在内存和单线程模型这片土壤里。