Redis源码剖析——线程模型
一、Redis 是单线程吗？
Redis 单线程指的是「接收客户端请求->解析请求 ->进行数据读写等操作->发送数据给客户端」这个过程是由一个线程（主线程）来完成的，这也是我们常说 Redis 是单线程的原因。
但是，Redis 程序并不是单线程的，Redis 在启动的时候，是会启动后台线程（BIO）的：
「关闭文件、AOF 刷盘、释放内存」这些任务需要创建单独的线程来处理，因为这些任务的操作都是很耗时的，如果把这些任务都放在主线程来处理，那么 Redis 主线程就很容易发生阻塞，这样就无法处理后续的请求了。
后台线程相当于一个消费者，生产者把耗时任务丢到任务队列中，消费者不停轮询这个队列，拿出任务就去执行对应的方法即可。
关闭文件、AOF 刷盘、释放内存这三个任务都有各自的任务队列：
BIO_CLOSE_FILE，关闭文件任务队列：当队列有任务后，后台线程会调用 close(fd) ，将文件关闭；
BIO_AOF_FSYNC，AOF刷盘任务队列：当 AOF 日志配置成 everysec 选项后，主线程会把 AOF 写日志操作封装成一个任务，也放到队列中。当发现队列有任务后，后台线程会调用 fsync(fd)，将 AOF 文件刷盘，
BIO_LAZY_FREE，lazy free 任务队列：当队列有任务后，后台线程会 free(obj) 释放对象 / free(dict) 删除数据库所有对象 / free(skiplist) 释放跳表对象；
二、Redis 单线程模式是怎样的？
Redis 6.0 版本之前的单线模式如下图：
Redis 初始化的时候，会做下面这几件事情：
- 首先，调用 epoll_create() 创建一个 epoll 对象和调用 socket() 创建一个服务器套接字 socket；
- 然后，调用 bind() 绑定端口和调用 listen() 设置监听该套接字；
- 然后，将调用 epoll_ctl() 将该监听套接字listen socket 加入到 epoll红黑树柄，同时注册「连接请求」处理函数。
初始化完后，主线程就进入到一个事件循环函数，主要会做以下事情：
- 首先，先调用处理发送队列函数，每一次进入 epoll_wait 前都调用 beforesleep看是发送队列里是否有任务，如果有发送任务，则通过 write 函数将客户端发送缓存区里的数据发送出去，如果这一轮数据没有发送完，就会注册写事件处理函数，等待 epoll_wait 发现可写事件触发后再处理 。
- 接着，调用 epoll_wait 函数等待事件的到来：
- 如果是连接事件到来，则会调用连接事件处理函数，该函数会做这些事情：调用 accpet 获取已连接的 socket -> 调用 epoll_ctl 将已连接的 socket 加入到 epoll -> 注册「读事件」处理函数；
- 如果是读事件到来，则会调用读事件处理函数，该函数会做这些事情：调用 read 获的取客户端发送数据 -> 解析命令 -> 处理命令 -> 将客户端对象添加到发送队列 -> 将执行结果写到发送缓存送区等待发；
- 如果是写事件到来，则会调用写事件处理函数，该函数会做这些事情：通过 write 函数将客户端发送缓存区里的数据发送出去，如果这一轮数据没有发送完，就会继续注册写事件处理函数，等待 epoll_wait 发现可写后再处理 。
1.处理新连接请求
在连接请求处理函数acceptTcpHandler中，主要做了几件事情：
调用 accept 系统调用把用户连接给接收回来；
为这个新连接创建一个唯一 redisClient 对象；
将这个新连接添加到 epoll，并注册一个读事件处理函数；
2.处理客户连接上的可读事件
在读处理函数 readQueryFromClient 中主要做了这么几件事情：
解析并查找命令；
调用命令处理；
添加写任务到队列；
将输出写到缓存等待发送；
3.beforesleep 处理写任务队列
在 aeMain 函数中，每次在进入 aeProcessEvents 前都需要先进行 beforesleep 处理。该函数处理了许多工作，其中一项便是：遍历发送任务队列，并将 client 发送缓存区中的处理结果通过 write 发送到客户端手中；
值得注意的是，发送 write 并不总是能一次性发送完的。假如要发送的结果太大，而系统为每个 socket 设置的发送缓存区又是有限的；
在这种情况下， 判断仍然有未发送完的数据的话，就需要注册一个写事件处理函数到 epoll 上。等待 epoll 发现该 socket 可写的时候再次调用 sendReplyToClient进行发送。
三、Redis 采用单线程为什么还这么快？
之所以 Redis 采用单线程（网络 I/O 和执行命令）那么快，有如下几个原因：
- Redis 的大部分操作都在内存中完成，并且采用了高效的数据结构，因此 Redis 瓶颈可能是机器的内存或者网络带宽，而并非 CPU，既然 CPU 不是瓶颈，那么自然就采用单线程的解决方案了；
- Redis 采用单线程模型可以避免了多线程之间的竞争，省去了多线程切换带来的时间和性能上的开销，而且也不会导致死锁问题。
- Redis 采用了 I/O 多路复用机制处理大量的客户端 Socket 请求，IO 多路复用机制是指一个线程处理多个 IO 流，就是我们经常听到的 select/epoll 机制。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听 Socket 和已连接 Socket。内核会一直监听这些 Socket 上的连接请求或数据请求。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果
四、Redis 6.0 之前为什么使用单线程？
Redis官方给出的核心意思是：
- Redis 操作基于内存，CPU 并不是制约 Redis 性能表现的瓶颈所在；
- 带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗；
- 使用单线程模型也能并发的处理客户端的请求（多路复用 I/O）；
五、Redis 6.0 之后为什么引入了多线程？
虽然 Redis 的主要工作（网络 I/O 和执行命令）一直是单线程模型，但是在 Redis 6.0 版本之后，也采用了多个 I/O 线程来处理网络请求，这是因为随着网络硬件的性能提升，Redis 的性能瓶颈有时会出现在网络 I/O 的处理上。
所以为了提高网络 I/O 的并行度，Redis 6.0 对于网络 I/O 采用多线程来处理。但是对于命令的执行，Redis 仍然使用单线程来处理，所以大家不要误解 Redis 有多线程同时执行命令。
Redis 官方表示，Redis 6.0 版本引入的多线程 I/O 特性对性能提升至少是一倍以上。
Redis 6.0 版本支持的 I/O 多线程特性，默认情况下 I/O 多线程只针对发送响应数据，并不会以多线程的方式处理读请求。要想开启多线程处理客户端读请求，就需要把 Redis.conf 配置文件中的 io-threads-do-reads 配置项设为 yes。同时， Redis.conf 配置文件中提供了 IO 多线程个数的配置项。
//读请求也使用io多线程
io-threads-do-reads yes
// io-threads N，表示启用 N-1 个 I/O 多线程（主线程也算一个 I/O 线程）
io-threads 4
关于线程数的设置，官方的建议是如果为 4 核的 CPU，建议线程数设置为 2 或 3，如果为 8 核 CPU 建议线程数设置为 6，线程数一定要小于机器核数，线程数并不是越大越好。
因此， Redis 6.0 版本之后，Redis 在启动的时候，默认情况下会创建 6 个线程：
- Redis-server ： Redis的主线程，主要负责执行命令；
- bio_close_file、bio_aof_fsync、bio_lazy_free：三个后台线程，分别异步处理关闭文件任务、AOF刷盘任务、释放内存任务；
- io_thd_1、io_thd_2、io_thd_3：三个 I/O 线程，io-threads 默认是 4 ，所以会启动 3（4-1）个 I/O 多线程，用来分担 Redis 网络 I/O 的压力。
六、Redis6.0版本的多线程处理模型
1.多线程模型
主线程工作流程如下：
- 主线程负责接收建立连接请求，将epoll_wait等待的读事件加入全局待处理列表中；
- 将等待列表中的读事件平均分给IO线程；
- 主线程处理其中一部分读事件；
- 阻塞等待IO线程将分配到的读事件进行命令解析；
- 当所有IO线程将分配到的读事件都命令解析完毕，主线程负责执行命令，并将回复信息写入客户端对应的回复缓冲区。
- 将等待等待列表中写事件平均分给IO线程；
- 主线程处理其中一部分写事件；
2.开启多线程后，是否会存在线程并发安全问题？
从上面的实现机制可以看出，Redis的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行。所以我们不需要去考虑控制 key、lua、事务，LPUSH/LPOP 等等的并发及线程安全问题。
3.Redis多线程模型缺陷
随着互联网的飞速发展，互联网业务系统所要处理的线上流量越来越大，Redis 的程单线模式会导致系统消耗很多 CPU 时间在网络 I/O 上从而降低吞吐量，于是诞生了Redis6.0多线程模型。
但是 Redis 多线程网络模型实际上并不是一个标准的 Multi-Reactors/Master-Workers模型。Redis 的多线程方案中，I/O 线程任务仅仅是通过 socket 读取客户端请求命令并解析，却没有真正去执行命令。所有客户端命令最后还需要回到主线程去执行，因此对多核的利用率并不算高，而且每次主线程都必须在分配完任务之后忙轮询等待所有 I/O 线程完成任务之后才能继续执行其他逻辑。
在我看来，Redis 目前的多线程方案更像是一个折中的选择：既保持了原系统的兼容性，又能利用多核提升 I/O 性能。
七、时间事件处理
Redis 的时间事件分为以下两类：
- 定时事件：让一段程序在指定的时间之后执行一次。
- 周期性事件：让一段程序每隔指定时间就执行一次。
一个时间事件是定时事件还是周期性事件取决于时间处理器的返回值：
- 如果返回值是 AE_NOMORE，那么这个事件是一个定时事件，该事件在达到后删除，之后不会再重复。
- 如果返回值是非 AE_NOMORE 的值，那么这个事件为周期性事件，当一个时间事件到达后，服务器会根据时间处理器的返回值，对时间事件的 when 属性进行更新，让这个事件在一段时间后再次达到。
服务器所有的时间事件都放在一个无序链表中，每当时间事件执行器运行时，它就遍历整个链表，查找所有已到达的时间事件，并调用相应的事件处理器。正常模式下的Redis服务器只使用serverCron一个时间事件，而在benchmark模式下，服务器也只使用两个时间事件，所以不影响事件执行的性能。