1. Redis 线程模型

1.1 IO 模型

阻塞 IO（Blocking IO）
非阻塞 IO（Nonblocking IO）
IO 多路复用（IO Multiplexing）
信号驱动 IO（Signal Driven IO）
异步 IO（Asynchronous IO）

1.1.1 阻塞 IO

应用程序想要去读取数据，他是无法直接去读取磁盘数据的，他需要先到内核里边去等待内核操作硬件拿到数据，这个过程就是 1，是需要等待的，等到内核从磁盘上把数据加载出来之后，再把这个数据写给用户的缓存区，这个过程是 2，如果是阻塞 IO，那么整个过程中，用户从发起读请求开始，一直到读取到数据，都是一个阻塞状态。

阶段一：

用户进程尝试读取数据（比如网卡数据）
此时数据尚未到达，内核需要等待数据
此时用户进程也处于阻塞状态

阶段二：

数据到达并拷贝到内核缓冲区，代表已就绪
将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据

1.1.2 非阻塞 IO

阶段一：

用户进程尝试读取数据（比如网卡数据）
此时数据尚未到达，内核需要等待数据
返回异常给用户进程
用户进程拿到 error 后，再次尝试读取
循环往复，直到数据就绪

阶段二：

将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据
可以看到，非阻塞 IO 模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致 CPU 空转，CPU 使用率暴增。

1.1.3 IO 多路复用

看个概念:
文件描述符（File Descriptor）：简称 FD，是一个从 0 开始的无符号整数，用来关联 Linux 中的一个文件。在 Linux 中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字（Socket）。

通过 FD，可以利用一个线程监听多个 FD，并在某个 FD 可读、可写时得到通知，从而避免无效的等待，充分利用 CPU 资源。

阶段一：

用户进程调用 select，指定要监听的 FD 集合
内核监听 FD 对应的多个 socket
任意一个或多个 socket 数据就绪则返回 readable
此过程中用户进程阻塞

阶段二：

用户进程找到就绪的 socket
依次调用 recvfrom 读取数据
内核将数据拷贝到用户空间
用户进程处理数据

1.1.3.1 IO 多路复用-select

简单说，就是我们把需要处理的数据封装成 FD，然后在用户态时创建一个 fd 的集合（这个集合的大小是要监听的那个 FD 的最大值+1，但是大小整体是有限制的），这个集合的长度大小是有限制的，同时在这个集合中，标明出来我们要控制哪些数据。

比如要监听的数据，是 1,2,5 三个数据，此时会执行 select 函数，然后将整个 fd 发给内核态，内核态会去遍历用户态传递过来的数据，如果发现这里边都数据都没有就绪，就休眠，直到有数据准备好时，就会被唤醒，唤醒之后，再次遍历一遍，看看谁准备好了，然后再将处理掉没有准备好的数据，最后再将这个 FD 集合写回到用户态中去，此时用户态就知道了，奥，有人准备好了，但是对于用户态而言，并不知道谁处理好了，所以用户态也需要去进行遍历，然后找到对应准备好数据的节点，再去发起读请求，我们会发现，这种模式下他虽然比阻塞 IO 和非阻塞 IO 好，但是依然有些麻烦的事情，比如说频繁的传递 fd 集合，频繁的去遍历 FD 等问题

假如传 1、2、5，2 好了，内核就直接返回 2

1.1.3.2 IO 多路复用-poll

IO 流程：

创建 pollfd 数组，向其中添加关注的 fd 信息，数组大小自定义
调用 poll 函数，将 pollfd 数组拷贝到内核空间，转链表存储，无上限
内核遍历 fd，判断是否就绪
数据就绪或超时后，拷贝 pollfd 数组到用户空间，返回就绪 fd 数量 n
用户进程判断 n 是否大于 0,大于 0 则遍历 pollfd 数组，找到就绪的 fd

与 select 对比：

select 模式中的 fd_set 大小固定为 1024，而 pollfd 在内核中采用链表，理论上无上限
监听 FD 越多，每次遍历消耗时间也越久，性能反而会下降

1.1.3.3 IO 多路复用-epoll

epoll 模式是对 select 和 poll 的改进，它提供了三个函数：

第一个是：eventpoll 的函数，他内部包含两个东西

一个是：

1、红黑树-> 记录的事要监听的 FD

2、一个是链表->一个链表，记录的是就绪的 FD

紧接着调用 epoll_ctl 操作，将要监听的数据添加到红黑树上去，并且给每个 fd 设置一个监听函数，这个函数会在 fd 数据就绪时触发，就是准备好了，现在就把 fd 把数据添加到 list_head 中去

3、调用 epoll_wait 函数

就去等待，在用户态创建一个空的 events 数组，当就绪之后，我们的回调函数会把数据添加到 list_head 中去，当调用这个函数的时候，会去检查 list_head，当然这个过程需要参考配置的等待时间，可以等一定时间，也可以一直等，如果在此过程中，检查到了 list_head 中有数据会将数据添加到链表中，此时将数据放入到 events 数组中，并且返回对应的操作的数量，用户态的此时收到响应后，从 events 中拿到对应准备好的数据的节点，再去调用方法去拿数据。

小总结：

select 模式存在的三个问题：

能监听的 FD 最大不超过 1024
每次 select 都需要把所有要监听的 FD 都拷贝到内核空间
每次都要遍历所有 FD 来判断就绪状态

poll 模式的问题：

poll 利用链表解决了 select 中监听 FD 上限的问题，但依然要遍历所有 FD，如果监听较多，性能会下降

epoll 模式中如何解决这些问题的？

基于 epoll 实例中的红黑树保存要监听的 FD，理论上无上限，而且增删改查效率都非常高
每个 FD 只需要执行一次 epoll_ctl 添加到红黑树，以后每次 epol_wait 无需传递任何参数，无需重复拷贝 FD 到内核空间
利用 ep_poll_callback 机制来监听 FD 状态，无需遍历所有 FD，因此性能不会随监听的 FD 数量增多而下降

1.1.4 信号驱动

信号驱动 IO 是与内核建立 SIGIO 的信号关联并设置回调，当内核有 FD 就绪时，会发出 SIGIO 信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待。

阶段一：

用户进程调用 sigaction，注册信号处理函数
内核返回成功，开始监听 FD
用户进程不阻塞等待，可以执行其它业务
当内核数据就绪后，回调用户进程的 SIGIO 处理函数

阶段二：

收到 SIGIO 回调信号
调用 recvfrom，读取
内核将数据拷贝到用户空间
用户进程处理数据

当有大量 IO 操作时，信号较多，SIGIO 处理函数不能及时处理可能导致信号队列溢出，而且内核空间与用户空间的频繁信号交互性能也较低。

1.1.5 异步 IO

这种方式，不仅仅是用户态在试图读取数据后，不阻塞，而且当内核的数据准备完成后，也不会阻塞

他会由内核将所有数据处理完成后，由内核将数据写入到用户态中，然后才算完成，所以性能极高，不会有任何阻塞，全部都由内核完成，可以看到，异步 IO 模型中，用户进程在两个阶段都是非阻塞状态。

1.2 Redis 线程模型

对于读写命令来说，Redis 一直是单线程模型。不过，在 Redis 4.0 版本之后引入了多线程来执行一些大键值对的异步删除操作， Redis 6.0 版本之后引入了多线程来处理网络请求（提高网络 IO 读写性能）。

Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型（Netty 的线程模型也基于 Reactor 模式，Reactor 模式不愧是高性能 IO 的基石），这套事件处理模型对应的是 Redis 中的文件事件处理器（file event handler）。由于文件事件处理器（file event handler）是单线程方式运行的，所以我们一般都说 Redis 是单线程模型。

文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

文件事件处理器（file event handler）主要是包含 4 个部分：

多个 socket（客户端连接）
IO 多路复用程序（支持多个客户端连接的关键）
文件事件分派器（将 socket 关联到相应的事件处理器）
事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

Redis I/O 多路复用的流程：

来源小林coding

首先进行初始化：

调用 epoll_create() 创建一个 epoll对象和调用socket()创建一个服务端socket
调用 bind() 绑定端口和调用 listen() 监听该 socket
将调用 epoll_ctl() 将 listen socket 加入到 epoll，同时注册连接事件处理函数

初始化完后，主线程就进入到一个事件循环函数，主要会做以下事情：

首先，先调用处理发送队列函数，看是发送队列里是否有任务，如果有发送任务，则通过 write 函数将客户端发送缓存区里的数据发送出去，如果这一轮数据没有发送完，就会注册写事件处理函数，等待 epoll_wait 发现可写后再处理。
接着，调用 epoll_wait 函数等待事件的到来：、
- 如果是连接事件到来，则会调用连接事件处理函数，该函数会做这些事情：调用 accpet 获取已连接的 socket -> 调用 epoll_ctl 将已连接的 socket 加入到 epoll -> 注册「读事件」处理函数；
- 如果是读事件到来，则会调用读事件处理函数，该函数会做这些事情：调用 read 获取客户端发送的数据 -> 解析命令 -> 处理命令 -> 将客户端对象添加到发送队列 -> 将执行结果写到发送缓存区等待发送；
- 如果是写事件到来，则会调用写事件处理函数，该函数会做这些事情：通过 write 函数将客户端发送缓存区里的数据发送出去，如果这一轮数据没有发送完，就会继续注册写事件处理函数，等待 epoll_wait 发现可写后再处理。

在Redis 6.0之后，redis采用了多个 I/O 线程来处理网络请求，默认情况下 I/O 多线程只针对发送响应数据，并不会以多线程的方式处理读请求。