前言

Redis是高性能分布式缓存常用中间件，我们经常说Redis是单线程的，
也有人说Redis在6.0版本采用了多线程，那么Redis到底是采用单线程呢？还是多线程？

通常说 Redis 是单线程，其实主要是指 Redis 对外提供键值存储服务的主要流程，
即网络 IO 和键值存储服务是由⼀个线程来完成的。

除此之外外的其他功能， 如持久化、 缓存过期、集群同步等，是由额外的线程执⾏的。
防止有同步阻塞，导致主线程被占用影响后续的逻辑执行。

Redis 为什么用单线程

Redis 单线程到底指什么？

大家所熟知的 Redis 确实是单线程模型，
指的是执行 Redis 命令的核心模块是单线程的，
而不是整个 Redis 实例就一个线程，Redis 其他模块还有各自模块的线程。

参见下图：

• aeApiPoll：事件分派，I/O 多路复用 API，是基于 epoll_wait/select/kevent 等系统调用的封装，监听等待读写事件触发，然后处理，它是事件循环（Event Loop）中的核心函数，是事件驱动得以运行的基础。
• acceptTcpHandler：连接应答处理器，底层使用系统调用 accept 接受来自客户端的新连接，并为新连接注册绑定命令读取处理器，以备后续处理新的客户端 TCP 连接；除了这个处理器，还有对应的 acceptUnixHandler 负责处理 Unix Domain Socket 以及 acceptTLSHandler 负责处理 TLS 加密连接。
• readQueryFromClient：命令读取处理器，解析并执行客户端的请求命令。
• sendReplyToClient：命令回复处理器，当一次事件循环之后写出缓冲区中还有数据残留，则这个处理器会被注册绑定到相应的连接上，等连接触发写就绪事件时，它会将写出缓冲区剩余的数据回写到客户端。

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器 。
它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。
因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。

优点

• Redis是基于内存的操作，磁盘IO以及CPU不是Redis的瓶颈，
  Redis的瓶颈最有可能是机器内存的大小和网络带宽。
• 采用单线程，避免了不必要的上下文切换和竞争条件，
  也不存在多进程或者多线程导致的切换而消耗 CPU。
• 不用去考虑各种锁的问题，不存在加锁释放锁操作，
  没有因为可能出现死锁而导致的性能消耗

Redis6.0 多线程

Redis 6.0
Redis 6.0 (GA October, 2021) introduced SSL, the new RESP3 protocol, ACLs, client side caching, diskless replicas, I/O threads, faster RDB loading, new modules APIs, and many more improvements.
See the release notes or download 6.0.16.

I/O threads 说的就是多线程。

多线程引入原因

多线程是 Redis6.0 推出的一个新特性。Redis 是核心线程负责网络 IO ，
命令处理以及写数据到缓冲， 而随着网络硬件的性能提升，
单个主线程处理⽹络请求的速度跟不上底层⽹络硬件的速度，
导致网络 IO 的处理成为了 Redis 的性能瓶颈。

而 Redis6.0 就是从单线程处理网络请求到多线程处理，
通过多个 IO 线程并⾏处理网络操作提升实例的整体处理性能。
需要注意的是对于读写命令，Redis 仍然使⽤单线程来处理，
这是因为继续使⽤单线程执行命令操作，就不⽤为了保证 Lua 脚本、事务的原⼦性，
额外开发多线程互斥机制了。

需要注意的是在 Redis6.0 中，多线程机制默认是关闭的，需要在 redis.conf 中
完成以下两个设置才能启用多线程。

设置 io-thread-do-reads 配置项为 yes，表示启用多线程。
io-threads-do-reads yes
设置线程个数。⼀般来说，线程个数要小于 Redis 实例所在机器的 CPU 核数，
例如，对于⼀个 8 核的机器来说，Redis 官⽅建议配置 6 个 IO 线程。
io-threads 6

多线程流程

全部流程主要分为 4 个阶段：

阶段一：服务端和客⼾端建立 Socket 连接，并分配处理线程

当有客⼾端请求和实例建立 Socket 连接时，主线程会创建和客户端的连接，
并把 Socket 放入全局等待队列中。然后主线程通过轮询方法把 Socket 连接
分配给 IO 线程。

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

主线程把 Socket 分配给 IO 线程后，会进⼊阻塞状态等待 IO 线程
完成客户端请求读取和解析。

阶段三：主线程执⾏请求操作

IO 线程解析完请求后，主线程以单线程的⽅式执⾏这些命令操作。

阶段四：IO 线程回写 Socket 和主线程清空全局队

主线程执行完请求操作后，会把需要返回的结果写入缓冲区。
然后，主线程会阻塞等待 IO 线程把这些结果回写到 Socket 中，
并返回给客户端。等到 IO 线程回写 Socket 完毕，主线程会清空全局队列，
等待客户端的后续请求。

小结

随着线上服务流量越来越大，Redis 的单线程模式会导致系统消耗很多 CPU 时间
在网络 I/O 上从而降低吞吐量，要提升 Redis 的性能有两个方向：

• 优化网络 I/O 模块
• 提高机器内存读写的速度

后者依赖于硬件的发展，暂时无解。所以只能从前者下手，网络 I/O 的优化又可以分为两个方向：

• 零拷贝技术或者 DPDK 技术
• 利用多核优势

模型缺陷

Redis 的多线程网络模型实际上并不是一个标准的 Multi-Reactors/Master-Workers 模型，
和其他主流的开源网络服务器的模式有所区别，
最大的不同就是在标准的 Multi-Reactors/Master-Workers 模式下，
Sub Reactors/Workers 会完成 网络读 -> 数据解析 -> 命令执行 -> 网络写 整套流程，Main Reactor/Master 只负责分派任务，
而在 Redis 的多线程方案中，I/O 线程任务仅仅是通过 socket 读取客户端请求命令并解析，却没有真正去执行命令，所有客户端命令最后还需要回到主线程去执行，因此对多核的利用率并不算高，而且每次主线程都必须在分配完任务之后忙轮询等待所有 I/O 线程完成任务之后才能继续执行其他逻辑。

Redis 之所以如此设计它的多线程网络模型，我认为主要的原因是为了保持兼容性，因为以前 Redis 是单线程的，所有的客户端命令都是在单线程的事件循环里执行的，也因此 Redis 里所有的数据结构都是非线程安全的，现在引入多线程，如果按照标准的 Multi-Reactors/Master-Workers 模式来实现，则所有内置的数据结构都必须重构成线程安全的，这个工作量无疑是巨大且麻烦的。

参考文章

https://blog.csdn.net/weixin_41605937/article/details/111982403
https://segmentfault.com/a/1190000041275783

更多技术文章，请关注公众号『码农札记』！！