redis I/O多路复用机制_redis io多路复用

一、基础回顾

1.1 多路复用要解决什么问题

并发多客户端连接场景，在多路复用之前最简单和典型的方案就是同步阻塞网络IO模型。 这种模式的特点就是用一个进程来处理一个网络连接(一个用户请求),比如一段典型的示例代码如下。

直接调用 recv 函数从一个 socket 上读取数据。

int main(){
 ...
 // //从用户角度来看非常简单，一个recv一用，要接收的数据就到我们手里了。
 recv(sock, ...) 
}
1
2
3
4
5

优点：就是这种方式非常容易让人理解，写起代码来非常的自然，符合人的直线型思维。
缺点：就是性能差，每个用户请求到来都得占用一个进程来处理，来一个请求就要分配一个进程跟进处理，

问题分析：

进程在 Linux 上是一个开销不小的家伙，先不说创建，光是上下文切换一次就得几个微秒。所以为了高效地对海量用户提供服务，必须要让一个进程能同时处理很多个 tcp 连接才行。现在假设一个进程保持了 10000 条连接，那么如何发现哪条连接上有数据可读了、哪条连接可写了 ？

也可以采用循环遍历的方式来发现 IO 事件，但是这种方式也存在耗费资源（上下文切换），系统调用的阻塞耗时等问题。

结论
所以就有了有一种更高效的机制，在很多连接中的某条上有 IO 事件发生的时候直接快速把它找出来。

就是Linux 操作系统中我们所熟知的 IO 多路复用机制。这里的复用指的就是对进程的复用

1.2 单线程如何处理并发连接？为什么快？

Redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，一次放到文件事件分派器，事件分派器将事件分发给事件处理器。

Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现

所谓 I/O 多路复用机制，就是说通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或写就绪），能够通知程序进行相应的读写操作。这种机制的使用需要 select 、 poll 、 epoll 来配合。多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。

Redis 服务采用 Reactor 的方式来实现文件事件处理器（每一个网络连接其实都对应一个文件描述符） Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。

它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。

1.3 同步&异步&阻塞&非阻塞

名词说明

• 同步：是指调用者要等待调用出结果后才能进行后续的执行（我现在就要，必须等到结果为止）；
• 异步：是指被调用方先给调用方返回应答，让调用方回去，然后计算调用结果，计算完最终结果后再返回给调用方。（一般通过回调的方式通知）
• 阻塞：调用方一直在等待而且别的什么事也不干（当前进程/线程会挂起）
• 非阻塞：调用发出后，先忙别的事情了，不会阻塞当前进程/线程，会立即返回。

4种组合方式的理解

二、IO 多路复用原理

2.1 阻塞式IO（BI/O）

BIO 简称：阻塞式 I/O，应用程序从调用 recvfrom 开始到它返回准备好的数据报这段时间是阻塞的，等 recvfrom返回成功后，应用程序才能开始处理数据。

1) 单线程 阻塞式 IO 调用过程

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

2) 单线程 阻塞式 I/O 模型存在的问题

如果客户端与服务端建立了连接，但是 这个连接的客户端迟迟不发数据，线程就会一直堵塞在read()方法上，这样其他客户端也不能进行连接，也就是一次只能处理一个客户端，对客户很不友好。

针对上面存在的问题，可以使用多线程来处理单线程的弊端。

2.2 多线程阻塞式IO模型

只要连接了一个socket，操作系统分配一个线程来处理，这样read()方法堵塞在每个具体线程上而不堵塞主线程，这样就能操作多个socket了，哪个线程中的socket有数据，就读哪个socket，各取所需，灵活统一。

1）多线程阻塞式 I/O 调用过程

程序服务端只负责监听是否有客户端连接，使用 accept() 阻塞

1. 客户端1连接服务端，就开辟一个线程（thread1）来执行 read() 方法，程序服务端继续监听
2. 客户端2连接服务端，也开辟一个线程（thread2）来执行 read() 方法，程序服务端继续监听
3. 客户端3连接服务端，也开辟一个线程（thread3）来执行 read() 方法，程序服务端继续监听

任何一个线程上的socket有数据发送过来，read()就能立马读到，cpu就能进行处理。

2）多线程 阻塞式 I/O 模型存在的问题

每来一个客户端，就要开辟一个线程，如果来1万个客户端，那就要开辟1万个线程。在操作系统中用户态不能直接开辟线程，需要调用内核来创建的一个线程，这其中还涉及到用户状态的切换（上下文的切换），十分耗资源。

针对上面多线程存在的问题，处理方案有两个：

方法一：使用线程池

这个在客户端连接少的情况下可以使用，但是用户量大的情况下，你不知道线程池要多大，太大了内存可能不够，也不可行。
注意：tomcat7 之前 就是用 BIO 的多线程来解决多连接的问题的。

方法二：使用 NIO（非阻塞 IO）方式

因为read()方法堵塞了，所有要开辟多个线程，如果什么方法能使read()方法不堵塞，这样就不用开辟多个线程了，这就用到了另一个IO模型，NIO（非阻塞式IO）。

小总结

思考：每个线程分配一个连接，必然会产生多个连接，既然是多个连接必然要放入容器统一管理。

2.3 非阻塞式IO（NIO）

在NIO模式中，一切都是非阻塞的：

1. accept()方法是非阻塞的，如果没有客户端连接，就返回无连接标识
2. read()方法是非阻塞的，如果read()方法读取不到数据就返回空闲中标识，如果读取到数据时只阻塞read()方法读数据的时间

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

1）非阻塞式 IO（NIO）的调用过程

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

2) 非阻塞式 IO 存在的问题

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

问题一：这个模型在客户端少的时候十分好用，但是客户端如果很多，比如有1万个客户端进行连接，那么每次循环就要遍历1万个socket，如果一万个socket中只有10个socket有数据，也会遍历一万个socket，就会做很多无用功，每次遍历遇到 read 返回 -1 时仍然是一次浪费资源的系统调用。
问题二：而且这个遍历过程是在用户态进行的，用户态判断socket是否有数据还是调用内核的read()方法实现的，这就涉及到用户态和内核态的切换，每遍历一个就要切换一次，开销很大因为这些问题的存在。

3) 优缺点

优点：不会阻塞在内核等待数据，每次发起的 I/O 请求可以立即返回，不用阻塞等待，实时性较好。
缺点：轮询将会不断地询问内核，这将占用大量的 CPU 时间，系统资源利用率较低，所以一般 Web 服务器不使用这种 I/O 模型。

小总结

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

2.4 IO Multiplexing 多路复用机制

1） 基础知识巩固

IO 多路复用的模型 :I/O多路复用( I/O multiplexing)，多个Socket复用一根网线这个功能是在内核＋驱动层实现的。

I/O multiplexing 这里面的 multiplexing 指的其实是在单个线程通过记录跟踪每一个Sock(I/O流)的状态来同时管理多个I/O流. 目的是尽量多的提高服务器的吞吐能力。

大家都用过nginx，nginx使用epoll接收请求，ngnix会有很多链接进来， epoll会把他们都监视起来，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。redis类似同理。

文件描述符 FileDescriptor: 文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

2）IO 多路复用工作过程

IO multiplexing就是我们说的select，poll，epoll，有些技术书籍也称这种IO方式为event driven IO事件驱动IO。

就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。可以基于一个阻塞对象并同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程，每次new一个线程)，这样可以大大节省系统资源。

所以，I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select，poll，epoll等函数就可以返回。

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

三、select&poll&epoll 多路复用的实现

3.1 select 方法实现

select 是第一个实现（1983年，实现于BSD）

1) 用户态基于Java看实现思想

2）深入C语言看代码实现

select 函数监视的文件描述符分3类，分别是readfds、writefds和exceptfds，将用户传入的数组拷贝到内核空间，

调用后select函数会阻塞，直到有描述符就绪（有数据 可读、可写、或者有except）或超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。

当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。

方法核心实现分析



3） 优缺点

优点： select 其实就是把NIO中用户态要遍历的fd数组(我们的每一个socket链接，安装进ArrayList里面的那个)拷贝到了内核态，让内核态来遍历，因为用户态判断socket是否有数据还是要调用内核态的，所有拷贝到内核态后，这样遍历判断的时候就不用一直用户态和内核态频繁切换了。

从代码中可以看出，select系统调用后，返回了一个置位后的&rset，这样用户态只需进行很简单的二进制比较，就能很快知道哪些socket需要read数据，有效提高了效率。

缺点：

1. bitmap最大1024位，一个进程最多只能处理1024个客户端
2. &rset不可重用，每次socket有数据就相应的位会被置位
3. 文件描述符数组拷贝到了内核态(只不过无系统调用切换上下文的开销。（内核层可优化为异步事件通知）)，仍然有开销。select 调用需要传入 fd 数组，需要拷贝一份到内核，高并发场景下这样的拷贝消耗的资源是惊人的。（可优化为不复制）
4. select并没有通知用户态哪一个socket有数据，仍然需要O(n)的遍历。select 仅仅返回可读文件描述符的个数，具体哪个可读还是要用户自己遍历。（可优化为只返回给用户就绪的文件描述符，无需用户做无效的遍历）

4） 小总结

select方式，既做到了一个线程处理多个客户端连接（文件描述符），又减少了系统调用的开销（多个文件描述符只有一次 select 的系统调用 + N次就绪状态的文件描述符的 read 系统调用。

3.2 poll 方法实现

1997年实现了poll方法。

1）C语言的实现


2）相比 select 的优点

1、poll使用pollfd数组来代替select中的bitmap，数组没有1024的限制，可以一次管理更多的client。它和 select 的主要区别就是，去掉了 select 只能监听 1024 个文件描述符的限制。

2、当pollfds数组中有事件发生，相应的revents置位为1，遍历的时候又置位回零，实现了pollfd数组的重用

3）存在的问题缺陷分析

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

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

3.3 epoll 方法实现

2002年被实现，核心思想是拆分成了三步调用。

1）三步调用

第一步：epoll create 创建一个epoll句柄。

int epoll_create(int size)
1

第二步：epoll_ctl 向内核添加、修改或删除要监控的文件描述符。

int epoll_ctl(int epfd,int op,int fd,struct,epoll_event *event);
1

第三部：epoll_wait 类似发起了一次select() 调用。

int epoll_wait(int epfd,struct,epoll_event *event,
                                 int max_evnets,int timeout);
1
2

2) C语言实现


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性能的瓶颈。

3.4 三种实现对比

四、附件材料

1. 基于Java 代码模拟BIO单线程和多线程版的Socket连接以及NIO连接 【Github】