Redis线程结构到底是怎么回事，带你慢慢理清楚那些复杂的关系

开始）

很多人刚开始用Redis的时候,可能都听过一个说法：“Redis是单线程的，所以很快。” 这个说法流传很广，但它其实是一个需要仔细理解的、有点过时的说法，今天我们就来慢慢理清楚Redis内部那些复杂的线程关系，看看它到底是怎么工作的。

核心的“单线程”指的是什么？

我们要明确一点,Redis的“单线程”神话，主要指的是处理我们客户端发来的命令的核心部分，你执行一个SET key value或者GET key，这个命令的解析、执行、最后把结果返回给客户端，这整个流程是由一个主线程来串行处理的。

你可以把Redis想象成一个只有一个收银员的超市,无论来了多少顾客（客户端请求），这个收银员都必须一个一个地服务，他不能同时给两个顾客结账，这种设计有一个巨大的好处：避免了多线程环境下可怕的“锁”的问题，多线程编程里，为了确保数据安全，经常需要给数据加锁，而锁的竞争和管理会消耗很多性能，甚至可能导致死锁等复杂问题，Redis干脆就不要锁，所有命令排着队处理，简单粗暴，但非常有效。

那为什么单线程还能这么快呢？主要有两个原因：

1. 纯内存操作：数据都在内存里，读写速度极快，单个命令的执行时间非常短。
2. 非阻塞的I/O多路复用：这是关键，虽然收银员只有一个，但他非常聪明，他不会傻等着某个顾客慢慢从钱包里掏钱（网络传输数据），当顾客在掏钱时，他会先去看看其他已经准备好钱的顾客，在技术层面，这就是I/O多路复用技术（如epoll），允许一个线程监控大量的网络连接，一旦某个连接有数据来了，线程就去处理，这样，CPU时间就被充分利用起来了，不会浪费在等待网络I/O上。

现代Redis早已不是“纯粹”的单线程

随着Redis版本的演进和功能变多,完全靠一个主线程已经不够了，为了性能，Redis在几个特定的地方引入了额外的线程。

后台线程处理慢操作 有些操作是比较耗时的，如果让主线程来做，就会阻塞后面所有的命令，这是不能接受的，Redis把这些“脏活累活”交给了后台线程去异步处理，主要包括：

• 持久化：比如把数据快照写入磁盘（RDB），或者重写AOF日志文件，这些大量的磁盘I/O操作都由后台线程完成，主线程继续愉快地处理命令。
• 大Key的删除：当你删除一个非常大的Hash或者List时，释放大量内存可能需要一些时间，在Redis 4.0之后，这类删除操作也交给了后台线程，避免了主线程被卡住，你可以用UNLINK命令来代替DEL，就是为了触发异步删除。
• 其他慢操作：比如刷新AOF日志到磁盘的策略之一。

I/O线程（Redis 6.0的重大革新） 这是对“单线程”模型最大的突破，在Redis 6.0之前，虽然I/O多路复用机制很高效，但读数据（把客户端发来的命令从网络套接字里读出来） 和写数据（把执行结果写回网络套接字） 这两个动作本身，还是由主线程亲自完成的。

随着网络带宽的增加,比如万兆网卡的出现，读写网络数据这个活本身也变成了一个潜在的瓶颈，如果某个客户端的网络很慢，主线程在读写它的数据时还是会耗费不少时间。

Redis 6.0引入了多线程I/O，主线程的角色更像一个“项目经理”：

• 它依然通过I/O多路复用技术监控所有连接，当有连接可读时，它不再自己去读数据，而是把读取数据的任务分配给一个I/O线程池里的线程。
• I/O线程们并行地把命令数据读好，然后排好队。
• 关键点：命令的执行依然由主线程串行进行，主线程从队列里取出命令，一个个执行。
• 执行完成后,主线程再把需要返回的结果数据，交给I/O线程池去并行地写回给各个客户端。

这样一来,最耗时的网络读写操作被并行化了，而核心的命令执行逻辑依然保持单线程的无锁优势，可谓鱼与熊掌兼得，这个功能默认是关闭的，需要手动配置开启。

总结一下现在的Redis线程结构

现在的Redis（6.0及以上版本）的线程结构可以这样理解：

1. 一个主线程：它是大脑，负责核心命令的执行、管理任务、调度I/O线程等。
2. 一组后台线程：负责处理像持久化、大Key删除这样的慢操作，不阻塞主线程。
3. 一组I/O线程（可选）：负责网络数据的读取和发送，为主线程分担压力。

它们之间的关系是协作关系,主线程是绝对的核心，其他线程都是它的助手，帮助它处理那些会拖慢它速度的杂事，确保它能以最高的效率处理最重要的命令请求。

下次再有人说“Redis是单线程的”，你可以更准确地告诉他：“Redis的核心命令处理是单线程的，但为了整体性能，它在后台和I/O层面已经巧妙地使用了多线程。” 结束）