大家好，我是码哥，《Redis 高手心法》作者。本书获得前阿里 P9 级资深技术专家李运华的推荐。
进入正文......
在《Redis 为什么这么快》这篇文章中，我们已经知道 Redis 使用全局 dict 字典表 + 内存数据库 + 丰富高效的数据结构 + 单线程模型 + I/O 多路复用事件驱动框架使得 Redis 快到飞起。
Redis 的网络 I/O 以及键值对指令读写是由单个线程来执行的，避免了不必要的上再问切换和资源竞争，对于性能提升有很大的帮助。
然而，Redis 官方在 2020 年 5 月正式推出 6.0 版本，引入了 I/O 多线程模型。
“谢霸哥：“为什么之前是单线程模型？为什么 6.0 引入了 I/O 多线程模型？主要解决了什么问题？”
今天，咱们就详细的聊下 I/O 多线程模型带来的效果到底是黛玉骑鬼火，该强强，该弱弱；还是犹如光明顶身怀绝技的的张无忌，招招都是必杀技。
“谢霸哥：“码哥， Redis 6.0 之前单线程指的是 Redis 只有一个线程干活么？”
非也，我们通常说的单线程模型指的是 Redis 在处理客户端的请求时，包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理。
而其他的清理过期键值对数据、释放无用连接、内存淘汰策略执行、 生成 RDB 内存快照文件、AOF rewrite 等都是其他线程处理。
命令执行阶段，每一条命令并不会立马被执行，而是进入一个一个 socket 队列，当 socket 事件就绪则交给事件分发器分发到对应的事件处理器处理，单线程模型的命令处理如下图所示。
图 4-23
“谢霸哥：“为什么 Redis6.0 之前是单线程模型？”
以下是官方关于为什么 6.0 之前一直使用单线程模型的回答。
Redis 的性能瓶颈主要在于内存和网络 I/O，CPU 不会是性能瓶颈所在。
Redis 通过使用 每秒可以处理 100 万个请求，应用程序的所时候用的大多数命令时间复杂度主要使用 O(N) 或 O(log(N)) 的，它几乎不会占用太多 CPU。
单线程模型的代码可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。
Redis 通过基于 I/O 多路复用实现的 AE 事件驱动框架将 I/O 事件和事件事件融合在一起，实现高性能网络处理能力，再加上基于内存的数据处理，没有引入多线程的必要。
而且单线程机制让 Redis 内部实现的复杂度大大降低，Hash 的惰性 Rehash、Lpush 等等线程不安全的命令都可以无锁进行。
“谢霸哥：“既然单线程这么好，为什么 6.0 版本引入多线程模型？”
因为随着底层网络硬件性能提升，Redis 的性能瓶颈逐渐体现在网络 I/O 的读写上，单个线程处理网络读写的速度跟不上底层网络硬件执行的速度。
因为读写网络的 read/write 系统调用占用了 Redis 执行期间大部分 CPU 时间。所以 Redis 采用多个 I/O 线程来处理网络请求，提高网络请求处理的并行度。
需要注意的是，Redis 多 IO 线程模型只用来处理网络读写请求，对于 Redis 的读写命令，依然是单线程处理。
这是因为，网络 I/O 读写是瓶颈，可通过多线程并行处理可提高性能。而继续使用单线程执行读写命令，不需要为了保证 Lua 脚本、事务、等开发多线程安全机制，实现更简单。
“谢霸哥：“码哥，你真是斑马的脑袋，说的头头是道。”
我谢谢您嘞，主线程与 I/O 多线程共同协作处理命令的架构图如下所示。
图 4-24
“谢霸哥：“如何开启多线程呢？”
Redis 6.0 的多线程默认是禁用的，如需开启需要修改 配置文件的配置。
开启多线程后，还要设置线程数才能生效，同样是修改 配置文件。
“谢霸哥：“码老师，线程数是不是越多越好？”
当然不是，关于线程数的设置，官方有一个建议：线程数的数量最好小于 CPU 核心数，起码预留一个空闲核处理，因为 Redis 是主线程处理指令，如果系统出现频繁上下文切换，效率会降低。
比如 4 核的机器建议设置为 2 或 3 个线程，8 核的机器建议设置为 6 个线程，线程数一定要小于机器核数。
“谢霸哥：“码老师真厉害，就好像卖盆的进村一套一套的。我什么时候也能像你这样连贯又有逻辑的掌握 Redis。”
认真读 Redis 高手心法，长线放风筝慢慢来。
“谢霸哥：“主线程与 I/O 线程是如何实现协作呢？”
图 4-25
主要流程。
主线程负责接收建立连接请求，通过轮询将可读 分配给 I/O 线程绑定的等待队列。
主线程阻塞等待，直到 I/O 线程完成 读取和解析。
主线程执行 I/O 线程读取和解析出来的 Redis 请求命令。
主线程阻塞等待 I/O 线程将指令执行结果回写回 完毕。
主线程清空等待队列，等待下一次客户端后续的请求。
思路：将主线程 IO 读写任务拆分出来给一组独立的线程处理，使得多个 socket 读写可以并行化，但是 Redis 命令还是主线程串行执行。
大家注意第三和第五步，主线程并不是挂起线程让出 CPU 分片时间。而是通过 for 循环进行忙等，不断的检测所有 I/O 线程处理任务是否已经完成，完成再执行下一步。
看完流程图以及主要步骤，接着跟着源码走一个。通过 4.3 章节的学习，我们知道 Redis 是通过 的函数启动的，经过一系列的初始化操作后，调用 启动事件驱动框架，也就是整个 Redis 的核心。
初始化线程
I/O 多线程模型的开端也是由 的方法中的 来初始化，该方法内部会调用 的 来执行实际 I/O 线程初始化工作。
检查是否开启 I/O 多线程模型：默认不激活 I/O 多线程模型，当 redis.conf 的 io-threads 配置大于 1 并且小于 （128） 则表示开启 I/O 多线程模式。
创建 链表，用于保存每个线程需要处理的 I/O 任务。
创建子线程，创建的时候先上锁，挂起子线程不让其进入工作模式，等初始化工作完成再开启。
指定 I/O 线程的入口函数 ，I/O 线程开始工作。
I/O 线程核心函数
函数主要负责等待启动信号、执行特定的 I/O 操作，并在完成操作后重置线程状态，以便再次等待下一次启动信号。
待读取客户端任务分配
Redis 会在主线程 初始化服务器的时候会注册 函数，里面会调用 函数实现待处理任务分配逻辑。该函数的主要作用如下。
将所有待读的客户端平均分配到不同的 I/O 线程的列表中。
通过设置 和调用 函数，通知各个 I/O 线程开始处理可读取的客户端数据。
主线程也参与处理客户端读取，以确保更好的并发性能。
主线程等待所有 I/O 线程完成读取 socket 工作。
这种设计采用了“扇出 -> 扇入”的范式，通过将工作分发到多个 I/O 线程，再将结果合并回主线程，以提高并发性能。
待写回客户端任务分配
与上面类似， 函数里面会调用 函数实现可写客户端处理任务分配给 I/O 线程，源代码跟 类似，不贴了。差别就是这个函数处理的事情是把响应写回 socket。
将所有待写的客户端平均分配到不同的 I/O 线程的列表中。
设置 为 通知各个 I/O 线程开始处理可写的客户端数据。
主线程也参与处理客户端读取，以确保更好的并发性能。
主线程等待所有 I/O 线程完成读取 socket 工作。
Redis 的多线程网络模型实际上并不是一个标准的 Multi-Reactors/Master-Workers 模型，I/O 线程任务仅仅是通过 socket 读取客户端请求命令并解析，以及把指令执行结果回写给 socket ，没有真正去执行命令。
所有客户端命令最后还需要回到主线程去执行，因此对多核的利用率并不算高，而且每次主线程都必须在分配完任务之后忙轮询等待所有 I/O 线程完成任务之后才能继续执行其他逻辑。
在我看来，Redis 目前的多线程方案更像是一个折中的选择，只是黛玉骑鬼火，还未达到必杀技的阶段。
往期推荐
京东二面：Redis 为什么这么快？我说是纯内存操作，他对我笑了笑......
微服务架构中的服务注册与发现有哪些？Zookeeper、Eureka、Nacos、Consul 都有什么区别，实现原理是什么？
我的 2024 盘点来了 | 愿你我闯过人生的每一道关
