IO模型详解

心已赠人 2022-09-11 03:21 178阅读 0赞

### IO模型详解 ###

*  用户空间和内核空间
 *  缓存IO和直接IO
 *   *   *  缓存IO
         *  直接IO
 *  同步IO和异步IO
 *  阻塞IO和非阻塞IO
 *  五种IO模型
 *   *   *  同步阻塞IO
         *  同步非阻塞IO
         *  IO多路复用
         *  异步IO
 *  Redis IO多路复用技术以及epoll实现原理
 *   *   *  Redis epoll底层实现

# 用户空间和内核空间 #

Linux系统将虚拟内存划分两块：`User space(用户空间)`、`Kernel space(内核空间)`

*  内核空间：内核代码运行地方。可以执行任何命令，调用系统一切资源。
 *  用户空间：用户程序代码运行地方。不能直接用户系统资源，必须通过系统接口(System call)才能向内核发出指令。

当进程运行在内核空间时就处于内核态，当进程运行在用户空间时就处于用户态。

str = "my string" // 用户空间 
    x=x+2
    file.write(str) // 切换到内核空间 
    y = x + 4 // 切换回用户空间

# 缓存IO和直接IO #

> 缓存IO：数据通过DMA从磁盘copy到内核空间，由cpu从内核空间copy到用户空间。  
> 直接IO：数据通过DMA从磁盘copy到用户空间。

### 缓存IO ###

缓存IO被称作标准IO，大多数文件系统都采用缓存IO。

*  读操作：检查缓存区是否有需要的数据，如果有直接返回，否则从磁盘中读取再放入缓存中。
 *  写操作：将用户空间数据复制到内核空间缓存中，这时对用户来说已经完成写操作，至于什么写到磁盘由操作系统决定。

**优点**

1.  在一定程序分离了内核空间和用户空间，保护系统运行安全。
2.  可以减少读写磁盘次数，从而提高性能。

**缺点**

1.  在缓存IO中，DMA可以将数据从磁盘读到缓存中，也可以从缓存写入到磁盘中，而不能在应用程序空间和磁盘空间之间数据传输，这样数据在传输过程需要在用户空间和内核空间来回copy，对cpu以及内存开销非常大。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATGFpbGFpTW9ua2V5_size_20_color_FFFFFF_t_70_g_se_x_16]

### 直接IO ###

直接IO就是应用程序直接访问磁盘数据，而不经过内核缓冲区，自己管理IO缓冲区，这样目的减少一次内核缓存区到用户程序缓存的数据复制。

引用缓存区目的在于提高磁盘文件访问性能，当进程需要读取磁盘文件时，如果文件内容已经在内核缓冲区则不需要读取磁盘。当进程需要写磁盘文件时，只写到内核缓存区便告诉进行已经写入成功，而真正写入是通过一定策略进行延迟的。

对于一些复杂应用(数据库)，为了提高性能希望绕过缓存区，由用户态管理缓存区，提高程序性能。

**优点**

1.  减少一次从内核缓冲区到用户缓冲区操作。

**缺点**

1.  如果数据不在应用缓存中，会读取磁盘，性能缓慢。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATGFpbGFpTW9ua2V5_size_11_color_FFFFFF_t_70_g_se_x_16]

# 同步IO和异步IO #

同步和异步是针对应用程序和内核交互而言，同步指的是用户进程触发IO操作并等待或轮询去查看IO操作是否就绪，而异步指用户进程触发IO操作以后便开始做自己的事，当IO完成时会得到通知。

> 用户空间和内核空间交互方式：  
> 同步IO：用户空间需要数据，必须等内核空间给它才做其它事情。  
> 异步IO：用户空间需要数据，不需要等内核空间给它，内核空间会异步通知用户进程，并把数据直接给到用户空间。

# 阻塞IO和非阻塞IO #

阻塞方式下读取或写入函数将一直等待完成，而非阻塞方式下读取或写入函数立即返回一个状态值。

> 用户空间和内核空间IO操作方式  
> 阻塞IO：用户空间通过系统调用(Systemcall)和内核空间发送IO操作，该调用是阻塞的。  
> 非阻塞IO：用户空间通过系统调用(Systemcall)和内核空间发送IO操作，该调用是不阻塞的，直接返回，只是返回时可能没有数据。

# 五种IO模型 #

服务器端编程经常需要构造高性能的IO模型，常见的IO模型有四种:

1.  同步阻塞IO(Blocking IO):即传统的IO模型。
2.  同步非阻塞IO(Non-blocking IO):默认创建的socket都是阻塞的，非阻塞IO要求socket被设置为 NONBLOCK。注意这里所说的NIO并非Java的NIO(New IO)库。
3.  IO多路复用(IO Multiplexing):即经典的Reactor设计模式，有时也称为异步阻塞IO，Java中的 Selector和Linux中的epoll都是这种模型。
4.  异步IO(Asynchronous IO):即经典的Proactor设计模式，也称为异步非阻塞IO。

*  举例理解1：

> 1、阻塞IO：给女神发一条信息，说我来找你了，然后默默的等待女神下楼，这个期间除了等待你不会干其它事情，属于备胎做法。  
> 2、非阻塞IO：给女神发信息，如果不回接着发，一直发到女神下楼，这个期间你除了发短信等待不会做其他事情，属于专一做法。  
> 3、IO多路复用：找一个宿管大妈帮你监视下楼女生，这个期间你可以做其它事情，例如你可以玩玩游戏、看看其它妹子等等。IO复用包括select、poll、epoll模式，它们区别是什么呢？  
> 3.1、select大妈，每一个下楼女生都不知道是不是你的女神，她需要一个一个询问，并且select大妈能力有限，一次只能监视1024个妹子，  
> 3.2、poll大妈，不限制女生数量，只要经过宿舍门口女生，都会帮你询问。  
> 3.3、epoll大妈，不限制女生数量，并且也不需要一个一个询问，epoll大妈为每个进宿舍楼的女生脸上帖一个字条（名字），只要女生下楼了，epoll女生就知道这个是不是你的女神然后再通知你。

上面这些同步IO有一个共同特点：当女神走出宿舍时候，你已经在宿舍门口，此时你属于同步等待状态。

接下来异步IO就是，你告诉女神我来了，然后就去打游戏了，直到女神下楼发现你不见了，女神再打电话通知你，说我下楼了，你在哪呢？这时候你再来宿舍门口，此时属于逆袭做法。

*  举例理解2：

> 1、阻塞IO：老李去火车站买车票，排队三天买一张车票。耗费：这三天全在车站，其它一件事情也没干。  
> 2、非阻塞IO：老李去火车站买车票，隔12小时去车站问问有没有票，三天后买到一张票。耗费：往返车站6次，路上6小时，其它时间做了好多事情。  
> 3、IO多路复用：select/poll模型，老李去火车站买票，然后每隔6小时电话询问黄牛，黄牛三天内买到票，然后老李交钱领票。耗费：往返车站2次，路上2小时，黄牛手续费100元，打电话17次。epoll模型，老李去火车站买车票，委托黄牛，黄牛买到后通知老李去领，然后老李去火车站交钱。耗费：往返车站2次，路上2小时，黄牛手续费100元。  
> 4、信号驱动IO模型：老李去火车站买票，给售票员留下电话，有票后电话通知老李，然后老李去火车站取票。耗费：往返车站2次，路上2小时。  
> 5、异步IO模型：老李去火车站买票，给售票员留下电话，有票后快递上门并通知老李。耗费：往返车站1次，路上1小时。

### 同步阻塞IO ###

同步阻塞IO模型是最简单的IO模型，用户线程在内核进行IO操作时被阻塞。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATGFpbGFpTW9ua2V5_size_11_color_FFFFFF_t_70_g_se_x_16 1]  
如图所示：用户线程通过系统调用read发起IO读操作，由用户空间转到内核空间。内核等到数据包到达后，然后将 接收的数据拷贝到用户空间，完成read操作。

### 同步非阻塞IO ###

同步非阻塞IO是在同步阻塞IO的基础上，将socket设置为NONBLOCK。这样做用户线程可以发起IO请求后立即返回。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATGFpbGFpTW9ua2V5_size_11_color_FFFFFF_t_70_g_se_x_16 2]  
如图所示：由于socket是非阻塞的方式，因此用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据到达后，才真正读取到数据，继续执行。

### IO多路复用 ###

IO多路复用模型是建立在内核提供的多路分离函数select基础之上的，使用select函数可以避免同步非阻塞IO模型中轮询等待的问题。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATGFpbGFpTW9ua2V5_size_11_color_FFFFFF_t_70_g_se_x_16 3]  
如图所示：用户首先将需要进行IO操作的socket添加到select中，然后阻塞等待select系统调用返回。当数据到达时，socket被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行。

### 异步IO ###

“真正”的异步IO需要操作系统更强的支持。在IO多路复用模型中，事件循环将文件句柄的状态事件通知给用户线 程，由用户线程自行读取数据、处理数据。而在异步IO模型中，当用户线程收到通知时，数据已经被内核读取完毕， 并放在了用户线程指定的缓冲区内，内核在IO完成后通知用户线程直接使用即可。  
![在这里插入图片描述][5831409afdea433fbf554b12777842ce.png]  
如图所示，异步IO模型中，用户线程直接使用内核提供的异步IO的API发起read请求，且发起后立即返回，继续执行用户线程代码。不过此时用户线程已经将调用的AsynchronousOperation和CompletionHandler注册到内核，然后操作系统开启独立的内核线程去处理IO操作。当read请求的数据到达时，由内核负责读取socket中的数据，并写入用户指定的缓冲区中。最后内核将read的数据和用户线程注册的CompletionHandler分发给内部Proactor，Proactor将IO完成的信息通知给用户线程(一般通过调用用户线程注册的完成事件处理函数)，完成异步IO。

# Redis IO多路复用技术以及epoll实现原理 #

redis是一个单线程却性能非常好的内存数据库，主要用来作为缓存系统。redis采用网络IO多路复用技术来保证在多连接时候，系统高吞吐量。

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

select、poll、epoll都是IO多路复用一种机制。IO多路复用通过一种机制，可以监听多个文件描述符，一旦某个描述符就绪，能够通知程序进行相应操作。

redis的io模型主要是基于epoll实现的，不过它也提供了 select和kqueue的实 现，默认采用epoll。

> 设想一下如下场景:  
> 有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的 (事实上大部分场景都是这种情况)。如何实现这样的高并发?

在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让 操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。

如果没有I/O事件产生，我们的程序就会阻塞在select处。但是依然有个问题，我们从select那里仅仅知道了，有 I/O事件发生了，但却并不知道是那几个流(可能有一个，多个，甚至全部)，我们只能所有流，找出能读出数据，或者写入数据的流，对他们进行操作。

但是使用select，我们有O(n)的无差别轮询复杂度，同时处理的流越多，每一次无差别轮询时间就越长。

**总结select和poll缺点：**

1.  每次调用select/poll，都需要把fd(文件描述符)集合从用户态拷贝到内核态，这个开销在fd很多时会很大。
2.  同时每次调用select/poll都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大。
3.  针对select支持的文件描述符数量太小了，默认是1024。
4.  select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件。
5.  select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次 select调用还是会将这些文件描述符通知进程。
6.  select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次 select调用还是会将这些文件描述符通知进程。

epoll的设计和实现与select完全不同。epoll是poll的一种优化，返回后不需要对所有的fd进行遍历，在内核中维持了fd列表。select和poll是将这个内核列表维持在用户态，然后传递到内核中。与poll/select不同， epoll不再是一个单独的系统调用，而是由三个系统调用(epoll\_create/epoll\_ctl/epoll\_wait)组成，后面将会 看到这样做的好处。epoll在2.6以后的内核才支持。

1.  调用epoll\_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)。
2.  调用epoll\_ctl向epoll对象中添加这100万个连接的套接字
3.  调用epoll\_wait收集发生的事件的连接

**总结epoll优点：**

1.  epoll 没有最大并发连接的限制，上限是最大可以打开文件的数目，这个数字一般远大于 2048, **一般来说这个数目和系统内存关系很大** ，具体数目可以 cat /proc/sys/fs/file-max 察看。
2.  效率提升，epoll 最大的优点就在于它**只管你“活跃”的连接** ，而跟连接总数无关，因此在实际的网络环境中，epoll 的效率就会远远高于 select 和 poll 。
3.  内存拷贝，epoll 在这点上使用了“共享内存”，这个内存拷贝也省略了。

### Redis epoll底层实现 ###

当某一进程调用epoll\_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll 的使用方式密切相关。

eventpoll结构体如下所示:  
![在这里插入图片描述][aabc5777d9c04f0eb88042dfc041d45e.png]

每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll\_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。

而所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个 回调方法。这个回调方法在内核中叫ep\_poll\_callback,它会将发生的事件添加到rdlist双链表中。

在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示:  
![在这里插入图片描述][a9829795a6a846e39cbb4188c4041af2.png]  
当调用 epoll\_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即 可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。

**优点：**

1.  **不用重复传递**。我们调用epoll\_wait时就相当于以往调用select/poll，但是这时却不用传递socket句柄给内核，因为内核已经在epoll\_ctl中拿到了要监控的句柄列表。
2.  **在内核里，一切皆为文件**。所以，epoll向内核注册了一个文件系统，用于存储上述的被监控socket。当你调用 epoll\_create时，就会在这个虚拟的epoll文件系统里创建一个file结点。当然这个file不是普通文件，它只服务于epoll。

> epoll在被内核初始化时(操作系统启动)，同时会开辟出epoll自己的内核高速cache区，用于安置每一个我们想监控的socket，这些socket会以红黑树的形式保存在内核cache里，以支持快速的查找、插入、删除。这个内核高速cache区，就是建立连续的物理内存页，然后在之上建立slab层，简单的说，就是物理上分配好你 想要的size的内存对象，每次使用时都是使用空闲的已分配好的对象。

1.  **极其高效原因**。这是由于我们在调用epoll\_create时，内核除了帮我们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储以后epoll\_ctl传来的socket外，还会再建立一个list链表，用于存储准备就绪的事件，当epoll\_wait调用时，仅仅观察这个list链表里有没有数据即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。所以，epoll\_wait非常高效。

执行epoll\_create时，创建了红黑树和就绪链表，执行epoll\_ctl时，如果增加 socket句柄，则检查在红黑树中是否存在，存在立即返回，不存在则添加到树干 上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数 据。执行epoll\_wait时立刻返回准备就绪链表里的数据即可。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATGFpbGFpTW9ua2V5_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/859cece7a85b4e09b054c7b9850ec67b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATGFpbGFpTW9ua2V5_size_11_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/b1b787e106ef478e9b1411e58520f1b8.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATGFpbGFpTW9ua2V5_size_11_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/d4f9ccd4e90b4122bbdce00f803dcbe4.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATGFpbGFpTW9ua2V5_size_11_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/d60325563f614bf090ff3591a1d0d0be.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATGFpbGFpTW9ua2V5_size_11_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/36e44fb60f544f5ab159558883c139de.png
[5831409afdea433fbf554b12777842ce.png]: /images/20220828/f27ffa6c38884d3696b9db9acee054ec.png
[aabc5777d9c04f0eb88042dfc041d45e.png]: /images/20220828/b408d3775ba44684bfcd5d07a4843007.png
[a9829795a6a846e39cbb4188c4041af2.png]: /images/20220828/fa69f823c12b415f9aea3ce2e6602b6c.png