Redis单线程模型

我们常说Redis是单线程的，所有操作都是按照顺序线性执行，但是由于读写操作等待用户输入或输出都是阻塞的，因此IO操作在一般情况下不能直接返回，这会导致：某一文件的IO阻塞会使得整个进程无法对其他客户提供服务。因此Redis在新版本中引入了多路复用功能。

1. 几个常见问题

1.1 Redis是单线程模型？

Redis的版本有非常多，3.x、4.x、6.x，版本不同架构也是不同的，不限定版本问是否单线程不太严谨。
1）版本3.x，最早版本，也就是大家口口相传的redis是单线程。
2）版本4.x，严格意义上来说也不是单线程，而是负责客户端处理请求的线程是单线程，但是开始加了点多线程的东西（异步删除）
3）最新版本的6.0.x后，告别了刻板印象中的单线程，而采用了一种全新的多线程来解决问题。

1.1.1 早期单线程模型

在以前，Redis的网络IO和键值对的读写都是由一个线程来完成的，Redis的请求时包括获取（Socket读），解析，执行，内容返回（socket写）等都是由一个顺序串行的主线程处理，这就是所谓的单线程。

但此时，Redis的瓶颈就出现了：
I/O的读写本身是阻塞的，比如当socket中有数据的时候，Redis会通过调用先将数据从内核态空间拷贝到用户态空间，再交给Redis调用，而这个拷贝的过程就是阻塞的，当数据量越大时拷贝所需要的时间就越多，而这些操作都是基于单线程完成的。

1.1.2 新版本中的多路复用

在Redis6.0中新增加了多线程的功能来提高I/O读写性能，他的主要实现思路是将主线程的IO读写任务拆分给一组独立的线程去执行，这样就可以使多个socket的读写并行化了，采用I/O多路复用技术可以让单个线程高效处理多个连接请求（尽量减少网络IO的时间消耗），将最耗时的socket读取，请求解析，写入单独外包出去，剩下的命令执行仍然是由主线程串行执行和内存的数据交互。

结合上图可知，网络IO操作就变成多线程化了，其他核心部分仍然是线程安全的，是个不错的折中办法。 整个流程如下图所示：

1. 主线程负责接收建立链接请求，获取socket放入全局等待读取队列
2. 主线程处理完读事件后，将这些连接分配给这些IO线程
3. 主线程阻塞等待IO线程读取socket完毕
4. IO线程组收集各个socket输入进来的命令，收集完毕
5. 主线解除阻塞，程执行命令，执行完毕后输出结果数据
6. 主线程阻塞等待 IO 线程将数据回写 socket 完毕
7. 解除绑定，清空等待队列

1.2 Redis为什么快？

1）基于内存操作，Redis的所有数据都存在内存中，因此所有的运算都是内存级别的，所以他的性能比较高。
2）数据结构简单：Redis的数据结构都是专门设计的，而这些简单的数据结构的查找和操作的时间大部分复杂度都是O（1），因此性能比较强。
3）多路复用和非阻塞I/O，Redis使用I/O多路复用来监听多个socket链接客户端，这样就可以使用一个线程链接来处理多个请求，减少线程切换带来的开销，同时也避免了I/O阻塞操作。
4）主线程为单线程，避免上下文切换，因为是单线程模型，因此避免了不必要的上下文切换和多线程竞争（比如锁），这就省去了多线程切换带来的时间和性能上的消耗，而且单线程不会导致死锁问题的发生。

1.3 Redis性能瓶颈

说了这么多redis的优点，redis的性能瓶颈到底在哪里？

从cpu上看：
1）redis是基于内存的，因此减少了cpu将数据从磁盘复制到内存的时间
2）redis是单线程的，因此减少了多线程切换和恢复上下文的时间
3）redis是单线程的，因此多核cpu和单核cpu对于redis来说没有太大影响，单个线程的执行使用一个cpu即可

综上所述，redis并没有太多受到cpu的限制，所以cpu大概率不会成为redis的瓶颈。

而内存大小和网络IO才有可能是redis的瓶颈。

所以Redis使用了I/O多路复用模型，来优化redis。

2. Redis多路复用实现原理

Redis 服务器是一个事件驱动程序， 服务器处理的事件分为时间事件和文件事件两类。

• 文件事件：Redis 主进程中，主要处理客户端的连接请求与相应。
• 时间事件：fork 出的子进程中，处理如 AOF 持久化任务等。

由于 Redis 的文件事件是单进程，单线程模型，但是确保持着优秀的吞吐量，IO 多路复用起到了主要作用。

文件事件是对套接字操作的抽象，每当一个套接字准备好执行连接应答、写入、读取、关闭等操作时，就会产生一个文件事件。因为一个服务器通常会连接多个套接字，所以多个文件事件有可能会并发地出现。

IO 多路复用程序负责监听多个套接字并向文件事件分派器传送那些产生了事件的套接字。文件事件分派器接收 IO 多路复用程序传来的套接字，并根据套接字产生的事件的类型，调用相应的事件处理器。示例如图所示：

Redis 的 IO 多路复用程序的所有功能都是通过包装常见的 select、poll、evport 和 kqueue 这些 IO 多路复用函数库来实现的，每个 IO 多路复用函数库在 Redis 源码中都有对应的一个单独的文件。

Redis 为每个 IO 多路复用函数库都实现了相同的 API，所以 IO 多路复用程序的底层实现是可以互换的。如图：

Redis 把所有连接与读写事件、还有我们没提到的时间事件一起集中管理，并对底层 IO 多路复用机制进行了封装，最终实现了单进程能够处理多个连接以及读写事件。这就是 IO 多路复用在 redis 中的应用。

3. Unix网络编程中的5种IO模型

Unix网络编程中有5中IO模型：Blocking IO，NoneBlocking IO，IO multiplexing，signal driven IO和asynchronous IO。

3.1 BIO（阻塞IO）

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据（对于网络IO来说，很多时候数据在一开始还没有到达。比如，还没有收到一个完整的UDP包。这个时候kernel就要等待足够的数据到来）。这个过程需要等待，也就是说数据被拷贝到操作系统内核的缓冲区中是需要一个过程的。而在用户进程这边，整个进程会被阻塞（当然，是进程自己选择的阻塞）。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。所以，BIO的特点就是在IO执行的两个阶段都被block了。

3.2 NIO（非阻塞IO）

3.2.1 实现方式

当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。所以，NIO特点是用户进程需要不断的主动询问内核数据准备好了吗？

在非阻塞式 I/O 模型中，应用程序把一个套接口设置为非阻塞，就是告诉内核，当所请求的I/O操作无法完成时，不要将进程睡眠而是返回一个“错误”，应用程序基于 I/O 操作函数将不断的轮询数据是否已经准备好，如果没有准备好，继续轮询，直到数据准备好为止。

在NIO模式中，只有一个线程： 当一个客户端与服务端进行连接，这个socket就会加入到一个数组中，隔一段时间遍历一次，看这个socket的read()方法能否读到数据，这样一个线程就能处理多个客户端的连接和读取了。

3.2.2 问题和优缺点

NIO成功的解决了BIO需要开启多线程的问题，NIO中一个线程就能解决多个socket，但是还存在2个问题。

问题一： 这个模型在客户端少的时候十分好用，但是客户端如果很多， 比如有1万个客户端进行连接，那么每次循环就要遍历1万个socket，如果一万个socket中只有10个socket有数据，也会遍历一万个socket，就会做很多无用功，每次遍历遇到 read 返回 -1 时仍然是一次浪费资源的系统调用。

问题二： 而且这个遍历过程是在用户态进行的，用户态判断socket是否有数据还是调用内核的read()方法实现的，这就涉及到用户态和内核态的切换，每遍历一个就要切换一次，开销很大因为这些问题的存在。

优点：不会阻塞在内核的等待数据过程，每次发起的 I/O 请求可以立即返回，不用阻塞等待，实时性较好。

缺点：轮询将会不断地询问内核，这将占用大量的 CPU 时间，系统资源利用率较低，所以一般 Web 服务器不使用这种 I/O 模型。

结论：让Linux内核搞定上述需求，**我们将一批文件描述符通过一次系统调用传给内核由内核层去遍历，才能真正解决这个问题。**IO多路复用应运而生，也即将上述工作直接放进Linux内核，不再两态转换而是直接从内核获得结果，因为内核是非阻塞的。

问题升级：如何用单线程处理大量的链接？

3.3 IO Multiplexing（IO多路复用）

3.3.1 实现方式

IO multiplexing就是我们说的select，poll，epoll，有些地方也称这种IO方式为event driven IO事件驱动IO。就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程，每次new一个线程)，这样可以大大节省系统资源。所以，I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select()函数就可以返回。

假设你是一个监考老师，让30个学生解答一道竞赛考题，然后负责验收学生答卷，你有下面几个选择：

第一种选择：按顺序逐个验收，先验收A，然后是B，之后是C、D。。。这中间如果有一个学生卡住，全班都会被耽误,你用循环挨个处理socket，根本不具有并发能力。

第二种选择：你创建30个分身线程，每个分身线程检查一个学生的答案是否正确。 这种类似于为每一个用户创建一个进程或者线程处理连接。

第三种选择，你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理E和A。。。这种就是IO复用模型。Linux下的select、poll和epoll就是干这个的。

将用户socket对应的fd注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。这样，整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor反应模式。

Reactor设计模式 基于 I/O 复用模型：多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。

Reactor 模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor 模式也叫 Dispatcher 模式。即 I/O 多了复用统一监听事件，收到事件后分发(Dispatch 给某进程)，是编写高性能网络服务器的必备技术。

3.3.2 select、poll和epoll

select, poll, epoll 都是I/O多路复用的具体的实现。

1. select方法

   select函数监视的文件描述符分3类，分别是readfds、writefds和exceptfds，将用户传入的数组拷贝到内核空间，调用select函数后会进行阻塞，直到有描述符就绪（有数据 可读，可写或者有except）或者超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。

   • 优点
     • select其实就是把NIO中用户态要遍历的fd数组（我们的每一个socket链接，安装进ArrayList里面的那个）拷贝到了内核态，让内核态来遍历，因为用户态判断socket是否有数据还是要调用内核态的，所有拷贝到内核态后，这样遍历判断的时候就不用一直用用户态和内核态频繁切换了。
   • 缺点
     • bitmap最大1024位，一个进程最多只能处理1024个客户端
     • &rset不可重用，每次socket有数据就相应的位会被置位
     • 文件描述符数组拷贝到了内核态，仍然有开销。select调用需要传入fd数组，需要拷贝一份到内核，高并发场景下这样的拷贝消耗资源是惊人的。（可优化为不复制）
     • **select并没有通知用户态哪一个socket用户有数据，仍需要O（n）的遍历。**select仅仅返回可读文件描述符的个数，具体哪个可读还是要用户自己遍历。（可优化为只返回给用户就绪的文件描述符，无需用户做无效的遍历）

2. poll方法

   • 优点

     • poll使用pollfd数组来代替select中的bitmap，数组中没有1024的限制，去掉了select只能监听1024个文件描述符的限制。
     • 当pollfds数组中有事件发生，相应revents置置为1，遍历的时候又置位回零，实现了pollfd数组的重用

   • 缺点

     • pollfds数组拷贝到了内核态，仍然有开销
     • poll并没有通知用户态哪一个socket有数据，仍然需要O(n)的遍历

   • 问题

     poll 解决了select缺点中的前两条，其本质原理还是select的方法，还存在select中原来的问题：

     1、pollfds数组拷贝到了内核态，仍然有开销 2、poll并没有通知用户态哪一个socket有数据，仍然需要O(n)的遍历

3. epoll方法

   • epoll_create：创建一个 epoll 句柄
   • epoll_ctl：向内核添加、修改或删除要监控的文件描述符
   • epoll_wait：类似发起了select() 调用

   epoll的执行流程为：

   • 当有数据的时候，会把相应的文件描述符“置位”，但是epoll没有revent标志位，所以并不是真正的置位。这时候会把有数据的文件描述符放到队首。
   • epoll会返回有数据的文件描述符的个数
   • 根据返回的个数读取前N个文件描述符即可

3.3.3 总结

多路复用快的原因在于，操作系统提供了这样的系统调用，使得原来的 while 循环里多次系统调用， 变成了一次系统调用 + 内核层遍历这些文件描述符。 epoll是现在最先进的IO多路复用器，Redis、Nginx，linux中的Java NIO都使用的是epoll。 这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。 1、一个socket的生命周期中只有一次从用户态拷贝到内核态的过程，开销小 2、使用event事件通知机制，每次socket中有数据会主动通知内核，并加入到就绪链表中，不需要遍历所有的socket

在多路复用IO模型中，会有一个内核线程不断地去轮询多个 socket 的状态，只有当真正读写事件发送时，才真正调用实际的IO读写操作。因为在多路复用IO模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有真正有读写事件进行时，才会使用IO资源，所以它大大减少来资源占用。多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。 采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈

三个方法对比如下：

	select	poll	epoll
操作方式	遍历	遍历	回调
数据结构	bitmap	数组	红黑树
最大连接数	1024（x86）或2048（x64）	无上限	无上限
最大支持文件描述符数	一般有最大值限制	65535	65535
fd拷贝	每次调用select，都需要把fd集合从用户态拷贝到内核态	每次调用poll，都需要把fd集合从用户态拷贝到内核态	fd首次调用epoll_ctl拷贝，每次调用epoll_wait不拷贝
工作效率	每次调用都进行线性遍历，时间复杂度O(n)	每次调用都进行线性遍历，时间复杂度O(n)	事件通知方式，每当fd就绪，系统注册的回调函数被调用，将就绪fd放到readyList里面，时间复杂度O(1)

3.4 signal-driven IO（信号驱动IO）

在信号驱动式I/O模型中，应用程序使用套接口进行信号驱动I/O，并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据。

• 优点： 线程并没有在等待数据时被阻塞，可以提高资源的利用率
• 缺点： 信号I/O在大量IO操作时可能会因为信号队列溢出导致没法通知

信号驱动I/O尽管对于处理UDP套接字来说有用，即这种信号通知意味着到达一个数据报，或者返回一个异步错误。但是，对于TCP而言，信号驱动的I/O方式近乎无用，因为导致这种通知的条件为数众多，每一个来进行判别会消耗很大资源，与前几种方式相比优势尽失。

3.5 asynchronous IO（异步IO）

由POSIX规范定义，应用程序告知内核启动某个操作，并让内核在整个操作（包括将数据从内核拷贝到应用程序的缓冲区）完成后通知应用程序。这种模型与信号驱动模型的主要区别在于：信号驱动I/O是由内核通知应用程序何时启动一个I/O操作，而异步I/O模型是由内核通知应用程序I/O操作何时完成。

• 优点： 异步 I/O 能够充分利用 DMA 特性，让 I/O 操作与计算重叠
• 缺点： 要实现真正的异步 I/O，操作系统需要做大量的工作。目前 Windows 下通过 IOCP 实现了真正的异步 I/O，而在 Linux 系统下，Linux2.6才引入，目前 AIO 并不完善，因此在 Linux 下实现高并发网络编程时都是以 IO复用模型模式为主。

4. 参考文献

1. https://segmentfault.com/a/1190000041488709
2. https://juejin.cn/post/7015927248100261901
3. https://blog.csdn.net/LU_ZHAO/article/details/105190942