Redis是属于多线程还是单线程？不同版本之间有什么区别？

Redis 是属于单线程还是多线程？

Redis 是普及率最高的技术之一，不仅是面试会被经常问到，在工作中也是非常常用的，下面我们就深入的了解一下Redis。

首先，Redis 使用的到底是多线程还是单线程？

不同版本的 Redis 是不同的，在 Redis4.0 之前，Redis 是单线程运行的，但是单线程并不代表效率就低，像 Nginx、Nodejs 也是单线程程序，但是它们的效率并不低，因为底层采用了基于 epoll 的 IO 多路复用（后面说）。

此外 Redis 是基于内存操作的，它的瓶颈在于机器的内存、网络带宽，而不是 CPU，因为在你 CPU 还没达到瓶颈时你的内存可能就先满了、或者带宽达到瓶颈了。因此 CPU 不是主要原因，那么自然就采用单线程了。更何况使用多线程还会面临一些额外的问题，比如共享资源的保护等等，对于一个 CPU 不是主要瓶颈的键值对数据库而言，采用单线程是非常合适的。

简单来说，Redis 在 4.0 之前使用单线程的模式是因为以下三个原因：

• 使用单线程模式的 Redis，其开发和维护会更简单，因为单线程模型方便开发和调试
• 即使使用单线程模型也能够并发地处理多客户端的请求，因为 Redis 内部使用了基于 epoll 的多路复用
• 对于 Redis 而言，主要的性能瓶颈是内存或者网络带宽，而并非 CPU

但 Redis 在 4.0 以及之后的版本中引入了惰性删除（也叫异步删除），这是由额外的线程执行的，意思就是我们可以使用异步的方式对 Redis 中的数据执行删除操作了，例如：unlink key、flushdb async、flushall async，举个例子：

127.0.0.1:6379> set name hanser

OK

127.0.0.1:6379> get name"hanser"

127.0.0.1:6379> unlink name  # 这里是异步删除一个 key，同步的话则是 del name

(integer) 1

127.0.0.1:6379> flushdb async

OK

127.0.0.1:6379> flushall async

OK

这样处理的好处就是不会使 Redis 的主线程卡顿，会把这些删除操作交给后台线程来执行。

通常情况下使用 del 指令可以很快的删除数据，但是当被删除的 key 是一个非常大的对象时，例如：删除的是包含了成千上万个元素的 hash 集合，那么 del 指令就会造成 Redis 主线程卡顿，因此使用惰性删除可以有效的避免 Redis 卡顿的问题。

除了惰性删除，像持久化、集群数据同步等等，都是由额外的子线程执行的，而 Redis 主线程则专注于网络 IO 和键值对读写。

在面试的时候，一旦涉及到 Redis，那么关于 Redis 线程模型的问题（单线程或多线程）几乎是必问的问题之一，但是回答好的人却并不多。大部分的人只能回答上来 Redis 是单线程的，以及说出单线程的众多好处，但对于 Redis4.0 和 Redis6.0 中，尤其是 Redis6.0 中多线程的特点，能够准确回答出来的人则非常少。关于单线程和多线程的相关知识，我们下面就来介绍。

 

Redis 既然是单线程的，为什么还这么快？

正如上面所说，Redis4.0 之前是单线程的，那既然是单线程为什么速度还能那么快？吞吐量还能那么高？

原因有以下几点：

• 基于内存操作：Redis 的所有数据都在内存中，因此所有的运算都是内存级别的，所以它的性能比较高
• 数据结构简单：Redis 的数据结构是为自身专门量身打造的，而这些数据结构的查找和操作的时间复杂度都是 O(1)
• 多路复用和非阻塞 I/O：Redis 使用 I/O 多路复用功能来监听多个 socket 连接客户端，这样就可以使用一个线程来处理多个情况，从而减少线程切换带来的开销，同时也避免了 I/O 阻塞操作，从而大大地提高了 Redis 的性能
• 避免上下文切换：因为是单线程模型，因此就避免了不必要的上下文切换和多线程竞争，这就省去了多线程切换带来的时间和性能上的开销，而且单线程不会导致死锁的问题发生

 

非阻塞 I/O 和 I/O 多路复用是什么？

首先我们可以使用 get 命令，获取一个 key 对应的 value，比如：

127.0.0.1:6379> get name"hanser"

那么问题来了，以上对于 Redis 服务端而言，都发生了哪些事情呢？

服务端必须要先监听客户端请求（bind/listen），然后当客户端到来时与其建立连接（accept），从 socket 中读取客户端的请求（recv），对请求进行解析（parse），这里解析出的请求类型是 get、key 是 "name"，再根据 key 获取对应 value，最后返回给客户端，也就是向 socket 写入数据（send）。

以上所有操作都是由 Redis 主线程依次执行的，但是里面会有潜在的阻塞点，分别是 accept 和 recv。当 Redis 监听到一个客户端有连接请求、但却一直未能成功建立连接，那么主线程会一直阻塞在 accept 函数这里，导致其它客户端无法和 Redis 建立连接。类似的，当 Redis 通过 recv 从客户端读取数据时，如果数据一直没有到达，那么 Redis 主线程也会一直阻塞在 recv 这一步，因此这就导致了 Redis 的效率会变得低下。

非阻塞 I/O

但很明显，Redis 不会允许这种情况发生，因为以上都是阻塞 I/O 会面临的情况，而 Redis 采用的是非阻塞 I/O，也就是将 socket 设置成了非阻塞模式。首先在 socket 模型中，调用 socket() 方法会返回 "主动套接字"，调用 bind() 方法绑定 IP 和 端口，再调用 listen() 方法将 "主动套接字" 转化为 "监听套接字"，最后 "监听套接字" 调用 accept() 方法等待客户端连接的到来，当和客户端建立连接时再返回 "已连接套接字"，而后续就通过 "已连接套接字" 来和客户端进行数据的接收与发送。

但是注意：我们说在 listen() 这一步，会将 "主动套接字" 转化为 "监听套接字"，而此时的 "监听套接字" 的类型是阻塞的，阻塞类型的 "监听套接字" 在调用 accept() 方法时，如果没有客户端来连接的话，就会一直处于阻塞状态，那么此时主线程就没法干其它事情了。所以在 listen() 的时候可以将其设置为非阻塞，而非阻塞的 "监听套接字" 在调用 accept() 时，如果没有客户端连接请求到达时，那么主线程就不会傻傻地等待了，而是会直接返回，然后去做其它的事情。

类似的，我们在创建 "已连接套接字" 的时候也可以将其类型设置为非阻塞，因为阻塞类型的 "已连接套接字" 在调用 send() / recv() 的时候也会处于阻塞状态，比如当客户端一直不发数据的时候，"已连接套接字" 就会一直阻塞在 rev() 这一步。如果是非阻塞类型的 "已连接套接字"，那么当调用 recv() 但却收不到数据时，也不用处于阻塞状态，同样可以直接返回去做其它事情。

但是有两点需要注意：

• 虽然 accept() 不阻塞了，在没有客户端连接时 Redis 主线程可以去做其它事情，但如果后续有客户端连接，Redis 要如何得知呢？因此必须要有一种机制，能够继续在 "监听套接字" 上等待后续连接请求，并在请求到来时通知 Redis。
• send() / recv() 不阻塞了，相当于 I/O 的读写流程不再是阻塞的，读写方法都会瞬间完成并且返回，也就是它会采用能读多少就读多少、能写多少就写多少的策略来执行 I/O 操作，这显然更符合我们对性能的追求。但这样会面临一个问题，那就是当我们执行读取操作时，有可能只读取了一部分数据，剩余的数据客户端还没发过来，那么这些这些数据何时可读呢？同理写数据也是这种情况，当缓冲区满了，而我们的数据还没有写完，那么剩下的数据又何时可写呢？因此同样要有一种机制，能够在 Redis 主线程做别的事情的时候继续监听 "已连接套接字"，并且有数据可读写的时候通知 Redis。

这样才能保证 Redis 线程既不会像基本 IO 模型中一直在阻塞点等待，也不会无法处理实际到达的客户端连接请求和可读写的数据，而上面所提到的机制便是 I/O 多路复用。

I/O 多路复用

I/O 多路复用机制是指一个线程处理多个 IO 流，也就是我们经常听到的 select/poll/epoll，而 Linux 采用的是 epoll。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中同时存在多个监听套接字和已连接套接字。内核会一直监听这些套接字上的连接请求或数据请求，一旦有请求到达就会交给 Redis 线程处理，这样就实现了一个 Redis 线程处理多个 IO 流的效果。

 

上图就是基于多路复用的 Redis IO 模型，图中的 FD 就是套接字，可以是 "监听套接字"、也可以是 "已连接套接字"，Redis 会通过 epoll 机制来让内核帮忙监听这些套接字。而此时 Redis 线程或者说主线程，不会阻塞在某一个特定的套接字上，也就是说不会阻塞在某一个特定的客户端请求处理上。因此 Redis 可以同时和多个客户端连接并处理请求，从而提升并发性。

但为了在请求到达时能够通知 Redis 线程，epoll 提供了基于事件的回调机制，即针对不同事件的发生，调用相应的处理函数。

那么回调机制是怎么工作的呢？以上图为例，首先 epoll 一旦监测到 FD 上有请求到达时，就会触发相应的事件。这些事件会被放进一个队列中，Redis 主线程会对该事件队列不断进行处理，这样一来 Redis 就无需一直轮询是否有请求发生，从而避免资源的浪费。同时，Redis 在对事件队列中的事件进行处理时，会调用相应的处理函数，这就实现了基于事件的回调。因为 Redis 一直在对事件队列进行处理，所以能及时响应客户端请求，提升 Redis 的响应性能。

我们以实际的连接请求和数据读取请求为例，再解释一下。连接请求和数据读取请求分别对应 Accept 事件和 Read 事件，Redis 分别对这两个事件注册 accept 和 get 回调函数，当 Linux 内核监听到有连接请求或数据读取请求时，就会触发 Accept 事件或 Read 事件，然后内核就会回调 Redis 注册的 accept 函数或 get 函数。

就像病人去医院看病，在医生实际诊断之前每个病人（类似于请求）都需要先分诊、测体温、登记等等。如果这些工作都有医生完成，那么医生的工作效率就会很低。所以医院设置了分诊台，分诊台会一直处理这些诊断前的工作（类似于 Linux 内核监听请求），然后再转交给医生做实际诊断，这样即使一个医生（相当于 Redis 的主线程）也能有很高的效率。

需要注意的时，不同的操作系统有着不同的多路复用实现，除了 Linux 的 epoll，还有 FreeBSD 的 kqueue、以及 Solaris 的 evport。

嗦一下 Redis 6.0 中的多线程

Redis 6.0 引入了一些新特性，其中非常受关注的一个特性就是多线程。在 4.0 之前 Redis 是单线程的，因为单线程的优点很明显，不但降低了 Redis 内部实现的复杂性，也让所有操作都可以在无锁的情况下进行，并且不存在死锁和线程切换带来的性能以及时间上的消耗。但是其缺点也很明显，单线程机制导致 Redis 的 QPS（Query Per Second，每秒查询数）很难得到有效的提高（虽然已经够快了，但人毕竟还是要有更高的追求的）。

而 Redis 从 4.0 版本开始引入了多线程，但是此版本的多线程主要用于大数据量的异步删除，对于非删除操作的意义并不是很大。

但 Redis 6.0 中的多线程则是真正为了提高 I/O 的读写性能而引入的，它的主要实现思路是将主线程的 I/O 读写任务拆分给一组独立的子线程去执行，也就是说从 socket 中读数据和写数据不再由主线程负责，而是交给了多个子线程，这样就可以使多个 socket 的读写并行化了。这么做的原因就在于，虽然在 Redis 中使用了 I/O 多路复用和非阻塞 I/O，但我们知道数据在内核态空间和用户态空间之间的拷贝是无法避免的，而数据的拷贝这一步是阻塞的，并且当数据量越大时拷贝所需要的时间就越多。所以 Redis 在 6.0 引入了多线程，用于分摊同步读写 I/O 压力，从而提升 Redis 的 QPS。但是注意：Redis 的命令本身依旧是由 Redis 主线程串行执行的，只不过具体的读写操作交给独立的子线程去执行了（后面会详细说明 Redis 的主线程和子线程之间是如何协同的），而这么做的好处就是不需要为 Lua 脚本、事务的原子性而额外开发多线程互斥机制，这样一来 Redis 的线程模型实现起来就简单多了。因为和之前一样，所有的命令依旧是由主线程串行执行的，只不过具体的读写任务交给了子线程。

除了引入多线程，还可以将内核网络协议栈换成用户态网络协议栈（DPDK），让网络请求不在内核里进行，直接在用户态完成。因为 socket 无论是发送数据还是接收数据都需要经过内核，发送数据时会将数据从用户态拷贝到内核态的缓冲区中，再由内核进行发送；接收数据，也是由内核负责接收，然后再将数据从内核态的缓冲区中拷贝到用户态。因此两个节点上的应用程序进行 socket 通信时，实际上是两个节点的内核进行交互，至于每个节点的应用程序则都是和自己的内核进行交互。

虽然替换协议栈可以避免频繁地让内核参与网络请求处理，提升请求处理效率，但是 Redis 并没有采用这种做法。原因就是该做法要求 Redis 的整体架构中，需要添加对用户态网络协议栈的支持，需要修改 Redis 源码中和网络相关的部分，这会带来很多额外的开发工作量；而且新增代码还可以引入 bug，导致 Redis 程序不稳定，因此 Redis 6.0 中没有采用这种做法。

请再具体嗦一下 Redis 6.0 的主线程和子线程之间是如何协同的？

整体可以分为四个阶段：

阶段一：服务端和客户端建立 socket 连接，并分配子线程（处理线程）

首先，主线程负责接收建立连接请求，当有客户端请求到达时，主线程会创建和客户端的 scoket 连接，该 socket 连接就是用来和客户端进行数据的传输的。只不过这一步不由主线程来做，主线程要做的事情是将该 socket 放入到全局等待队列中，然后通过轮训的方式选择子线程，并将队列中的 socket 连接分配给它，所以无论是从客户端读数据还是向客户端写数据，都由子线程来做。因为我们说 Redis 6.0 中引入多线程就是为了缓解主线程的 I/O 读写压力，而 I/O 读写这一步是阻塞的，所以应该交给子线程并行操作。

阶段二：子线程读取并解析请求

主线程一旦把 socket 连接分配给子线程，那么会进行阻塞状态，等待子线程完成客户端请求的读取和解析，得到具体的命令操作。由于可以有多个子线程，所以这个操作很快就能完成。

阶段三：主线程执行命令操作

等到子线程读取到客户端请求并解析完毕之后，然后再由主线程以单线程的方式执行命令操作，I/O 读写虽然交给了子线程，但是命令本身还是由 Redis 主线程执行的。

阶段四：子线程回写 socket、主线程清空全局队列

当主线程执行完命令操作时，还需要将结果写入缓冲区，而这一步显然要由子线程来做，因为是 I/O 读写。此时主线程会陷入阻塞，直到子线程将这些结果写回 socket 并返回给客户端。

和读取一样，子线程将数据写回 socket 时，也是有多个线程在并行执行，所以写回 socket 的速度也很快。之后主线程会清空全局队列，等待客户端的后续请求。

 

 

在 Redis 6.0 中如何开启多线程？

在了解了 Redis 6.0 中的多线程机制之后，我们要如何开启多线程呢？在 Redis 6.0 中，多线程机制默认是关闭的，如果想启动的话，需要修改 redis.conf 中的两个配置。

1. 设置 io-thread-do-reads 配置项为 yes，表示启用多线程。

io-thread-do-reads yes

2. 通过 io-threads 设置子线程的数量。

io-threads 3

表示开启 3 个子线程，但是注意，线程数要小于机器的 CPU 核数，线程数并不是越大越好。关于线程数的设置，官方的建议是如果为 4 核的 CPU，那么设置子线程数为 2 或 3；如果为 8 核的CPU，那么设置子线程数为 6。

如果你在实际应用中，发现 Redis 实例的 CPU 开销不大，吞吐量却没有提升，可以考虑使用 Redis 6.0 的多线程机制，加速 IO 读写处理，进而提升实例的吞吐量。

最后关于 Redis 的性能，Redis 的作者在 2019 的 RedisConf 大会上提到，Redis6.0 引入的多线程 I/O 特性对性能的提升至少是一倍以上。国内也有人在阿里云使用 4 个线程的 Redis 版本和单线程的 Redis 版本进行比较测试，发现测试的结果和 Redis 作者说的一致，性能基本可以提高一倍。

总结

以上我们就介绍了 Redis 在 4.0 之前明明采用单线程但却依然快的原因：基于内存操作、量身打造的数据结构、I/O 多路复用和非阻塞 I/O、避免了不必要的线程上下文切换。并且在 Redis4.0 开始支持多线程，主要体现在大数据的异步删除上面，例如：unlink key、flushdb async、flushall async 等。而 Redis6.0 的多线程则增加了对 I/O 读写的并发能力，因为数据在用户态和内核态之间穿梭是需要进行拷贝的，而这一步是阻塞的，所以通过多个线程并行操作从而更好的提升 Redis 的性能。