python epoll 并发_Python并发编程（八）：IO模型

下面是小凰凰的简介，看下吧！

💗人生态度：珍惜时间，渴望学习，热爱音乐，把握命运，享受生活

💗学习技能：网络 -> 云计算运维 -> python全栈( 当前正在学习中)

💗您的点赞、收藏、关注是对博主创作的最大鼓励，在此谢过！

有相关技能问题可以写在下方评论区，我们一起学习，一起进步。

后期会不断更新python全栈学习笔记，秉着质量博文为原则，写好每一篇博文。

一、iO模型介绍

为了更好地了解IO模型，我们需要事先回顾下：同步、异步、阻塞、非阻塞

本文讨论的背景是Linux环境下的network IO。本文最重要的参考文献是Richard Stevens的“UNIX® Network Programming Volume 1, Third Edition: The Sockets Networking ”，6.2节“I/O Models ”，Stevens在这节中详细说明了各种IO的特点和区别，如果英文够好的话，推荐直接阅读。Stevens的文风是有名的深入浅出，所以不用担心看不懂。本文中的流程图也是截取自参考文献。

Stevens在文章中一共比较了五种IO Model： blocking IO、nonblocking IO 、IO multiplexing 、signal driven IO 、asynchronous IO 由signal driven IO(信号驱动IO)在实际中并不常用，所以主要介绍其余四种IO Model。

一、阻塞IO(blocking IO)

在linux中，默认情况下socket网络编程中的recv、accept等大部分都是blocking，一个典型的读操作流程大概是这样：

最传统的一种IO模型，即在读写数据过程中会发生阻塞现象。

当用户发起recvfrom或recv时，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。

典型的阻塞IO模型的例子为：

data = socket.recv();

我们面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型也会遇到瓶颈，可以用非阻塞接口来尝试解决这个问题。

二、非阻塞IO(nonblocking IO)

当用户线程发起一个recv操作后，并不需要等待，而是马上就得到了一个结果。如果结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送recv操作。一旦内核中的数据准备好了，并且又再次收到了用户线程的请求，那么它马上就将数据拷贝到了用户线程，然后返回。

所以事实上，在非阻塞IO模型中，用户线程需要不断地询问内核数据是否就绪，也就说非阻塞IO不会交出CPU，而会一直占用CPU

三、IO多路复用(IO multiplexing)

多路复用IO模型是目前使用得比较多的模型。Java NIO实际上就是多路复用IO。

在多路复用IO模型中，会有一个线程不断去轮询多个socket的状态，只有当socket真正有读写事件时，才真正调用实际的IO读写操作。因为在多路复用IO模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有在真正有socket读写事件进行时，才会使用IO资源，所以它大大减少了资源占用。

不过要注意的是，多路复用IO模型是通过轮询的方式来检测是否有事件到达，并且对到达的事件逐一进行响应。因此对于多路复用IO模型来说，一旦事件响应体很大，那么就会导致后续的事件迟迟得不到处理，并且会影响新的事件轮询，事件太多，轮询周期太长。

四、异步IO(asynchronous IO)

异步IO模型才是最理想的IO模型，在异步IO模型中，当用户线程发起recv操作之后，立刻就可以开始去做其它的事。而另一方面，从内核的角度，当它受到一个asynchronous recv之后，它会立刻返回，说明read请求已经成功发起了，因此不会对用户线程产生任何block。然后，内核会等待数据准备完成，然后将数据拷贝到用户线程，当这一切都完成之后，内核会给用户线程发送一个信号，告诉它read操作完成了。也就说用户线程完全不需要关心实际的整个IO操作是如何进行的，只需要先发起一个请求，当接收内核返回的成功信号时表示IO操作已经完成，可以直接去使用数据了。

重点：

IO多路复用采用轮询的方式实现检测事件的到达，事件太多，轮询周期太长，造成效率低下。

异步IO采用异步回调的机制实现检测事件的到达，数据到达，立马触发异步回调机制，主动告诉内核，数据准备完成，然后内核将数据拷贝到用户线程，告诉用户线程recv完毕！

异步IO是需要操作系统的底层支持，在Java 7中，提供了Asynchronous IO。简称AIO

总结：前面四种IO模型实际上都属于同步IO，只有最后一种是真正的异步IO，因为无论是多路复用IO还是信号驱动模型，IO操作的第2个阶段都会引起用户线程阻塞，也就是内核等待数据的准备，然后进行数据拷贝的过程都会让用户线程阻塞。

有人可能想问非阻塞IO不是也不用等待吗，它为什么不是异步的？

1、首先高清楚同步、异步、阻塞、非阻塞的关系。'同步、异步区别是:是否原地等待数据的返回，阻塞和非阻塞区别是：是否会有程序的停顿！'

2、非阻塞是说明在recv处不会停在这里。'异步不仅仅是不停在哪里，而且运行recv过后就不管了'，有点类似于后台自己运行。只等着结果就行了。非阻塞还需要try捕捉异常操作。所以它不是异步的！

五、四种模型对比

四种模型中实际应用中IO多路复用使用的最多。

1、blocking和non-blocking的区别

调用blocking IO会一直block住对应的进程直到操作完成，而non-blocking IO在kernel还准备数据的情况下会立刻返回。

2、synchronous IO和asynchronous IO的区别

两者的区别就在于synchronous IO做”IO operation”的时候会将process阻塞。按照这个定义，四个IO模型可以分为两大类，之前所述的blocking IO，non-blocking IO，IO multiplexing都属于synchronous IO这一类，而 asynchronous I/O后一类 。

有人可能会说，non-blocking IO并没有被block啊。这里有个非常“狡猾”的地方，定义中所指的”IO operation”是指真实的IO操作，我们这只是感觉上，就是例子中的recvfrom这个system call。non-blocking IO在执行recvfrom这个system call的时候，如果kernel的数据还没有准备好，这时候不会block进程,而是会抛出异常，你可以捕捉异常，然后利用数据没准备好的这段时间去干其它事情。但是，当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被block了。而asynchronous IO则不一样，当进程发起IO 操作之后，就直接往下继续运行，再也不理睬了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被block。

六、三种实现IO多路复用的机制

因为我们的IO多路复用实际应用最多，因此讲下多路复用的实现的三种机制：select、poll、epoll，select在win和linux上都可以使用，poll、epoll只支持linux操作系统！

1、select与poll

# select的缺点：

1. 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；(在linux内核头文件中，有这样的定义：#define __FD_SETSIZE 1024)

2. 内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；

3. select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；

4. select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。

'相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。'

拿select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。

因此，select与poll这两种IO多路复用模型使用场景比较少。

2、epoll(推荐)

由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。

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

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

epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。它把原先的select/poll调用分成了3个部分：

1)调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)

2)调用epoll_ctl向epoll对象中添加这100万个连接的套接字

3)调用epoll_wait收集发生的事件的连接

如此一来，要实现上面说的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。