124 IO模型

时间  2019-11-20
标签 模型 繁體版
原文   原文链接

1、IO模型介绍

回顾：同步、异步、阻塞、非阻塞python

同步： 指的是协同步调。既然叫协同，因此至少要有2个以上的事物存在。协同的结果就是：多个事物不能同时进行，必须一个一个的来，上一个事物结束后，下一个事物才开始。linux

异步：就是步调各异，就是多个事物，你进行你的，我进行个人，谁都不用管谁，全部的事物都在同时进行中ios

总结：同步就是多个事物不能同时开工，异步就是多个事物能够同时开工。程序员

阻塞：因为执行任务过程当中遇到了阻塞，致使任务执行不了，处于等待的状态web

非阻塞：就是执行任务过程当中没有遇到阻塞，进而能够一直执行任务数据库

总结：回到程序里，阻塞一样意味着停下来等待，非阻塞代表能够继续向下执行。编程

1.阻塞I/O模型（blocking I/O）

2.非阻塞I/O模型（noblocking I/O）

3.I/O多道复用（I/O multiplexing）

4.信号驱动I/O（signal driven I/O）

5.异步I/O（asynchronous I/O）

前四个I/O都被称之为同步I/Owindows

I/O发生时涉及的对象和步骤：对于一个network I/O （网络I/O）(这里咱们以read举例)，它会涉及到两个系统对象，一个是调用这个I/O的process (or thread)，另外一个就是系统内核(kernel)。当一个read操做发生时，该操做会经历两个阶段：缓存

  1. 等待数据准备 (Waiting data )
  2. 将数据从内核拷贝到进程中(Copying data )

注意：以上两点和重要，由于在不一样的I/O模型中，在以上两个阶段各有不一样的状况tomcat

2、阻塞I/O模型

在linux中，默认状况下全部的socket都是blocking，一个典型的读操做流程大概是这样：

1569151255751

简单理解：就是用户进程在给服务端发送数据请求时，服务端可能不能当即给出返回数据，服务端要等待数据，这就形成了用户进程一直在原地等着，直到服务端数据准备好了，在将数据从本身内存中拷贝到用户内存中，而后用户进程接着执行作同日他的操做。

阻塞I/O特色：blocking I/O的特色就是在I/O执行的两个阶段（等待数据和拷贝数据两个阶段）都被block了。

实际上：几乎全部的I/O接口 ( 包括socket接口 ) 都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用recv(1024)的同时，线程将被阻塞，在此期间，线程将没法执行任何运算或响应任何的网络请求。

2.1 解决方法（启用多线程/多进程）

在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每一个链接都拥有独立的线程（或进程），这样任何一个链接的阻塞都不会影响其余的链接。

2.2 该方法的问题

开启多进程或都线程的方式，在遇到要同时响应成百上千路的链接请求，则不管多线程仍是多进程都会严重占据系统资源，下降系统对外界响应效率，并且线程与进程自己也更容易进入假死状态。

2.3 改进方案（线程池/进程池）

不少程序员可能会考虑使用“线程池”或“链接池”。“线程池”旨在减小建立和销毁线程的频率，其维持必定合理数量的线程，并让空闲的线程从新承担新的执行任务。“链接池”维持链接的缓存池，尽可能重用已有的链接、减小建立和关闭链接的频率。这两种技术均可以很好的下降系统开销，都被普遍应用不少大型系统，如websphere、tomcat和各类数据库等。

2.4 改进后方案的问题

“线程池”和“链接池”技术也只是在必定程度上缓解了频繁调用I/O接口带来的资源占用。并且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。因此使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。

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

3、非阻塞I/O模型

从图中能够看出，当用户进程向服务端发出请求数据时，若是服务端没有数据会当即给用户进程发送没有数据，此时，因而用户就能够在本次到下次再发起read询问的时间间隔内作其余事情，或者直接再次发送read操做。一旦服务端中的数据准备好了，而且又再次收到了用户进程的系统调用，那么它立刻就将数据拷贝到了用户内存（这一阶段仍然是阻塞的），而后返回。

也就是说非阻塞的用户京城recvform系统调用调用以后，进程并无被阻塞，内核立刻返回给进程，若是数据还没准备好，此时会返回一个error。进程在返回以后，能够干点别的事情，而后再发起recvform系统调用。重复上面的过程，循环往复的进行recvform系统调用。这个过程一般被称之为轮询。轮询检查内核数据，直到数据准备好，再拷贝数据到进程，进行数据处理。须要注意，拷贝数据整个过程，进程仍然是属于阻塞的状态。因此，在非阻塞式I/O中，用户进程实际上是须要不断的主动询问服务端数据准备好了没有。

3.1 非阻塞I/O实例

#服务端
import socket

server = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
server.bind(('127.0.0.1',8080))
server.listen()
server.setblocking(False)#设置socket的接口为非阻塞,只要没人连服务端就报错

conn_lis = []
del_conn = []
while True:
    try: # 只要没客户端连就报错，因此捕捉异常
        conn,addr = server.accept()
        conn.lis.append(conn)
    except:
        for conn in conn_lis:
            try:# recv也是一个阻塞阶段，只要没人发数据就报错，因此捕捉异常
                msg = conn.recv(1024)
                if msg == b'':
                    del_conn.append(conn)
                    continue
                 print(msg)
                conn.send(b'byebye')
             except:pass
         for conn in del_conn:
            conn_lis.remove(conn)
            conn.close()
         del_conn.clear()
#客户端
import socket
import time
from threading import thread
def action():
    while True:
        client = socket.socket()
        client.connect(('127.0.0.1',8080))
        client.send(b'hello')
        time.sleep(2)
        client.recv(1024)
        print(msg)
        client.close()
            
for i in range(20):
    t  = thread(target=action)
    t.start()

重要：非阻塞I/O模型毫不被推荐。

虽然可以在等待任务完成的时间里干其余活了（包括提交其余任务，也就是 “后台” 能够有多个任务在“”同时“”执行）。

  1. 可是咱们轮询的去调用recv会大大的提升cpu的占用率，致使效率变慢

  2. 任务完成的响应延迟增大了，由于每过一段时间才去轮询一次read操做，而任务可能在两次轮询之间的任意时间完成。这会致使总体数据吞吐量的下降。

4、I/O多路复用

I/O multiplexing（I/O多路复用）用到了select/poll模块，是操做系统提供的一种机制，select/poll的好处就在于单个用户process就能够同时处理多个网络链接的I/O。它的基本原理就是select/poll会不断的轮询所负责的全部socket，当某个socket有数据到达了，就通知用户进程。它的流程如图：

当用户进程调用了select，那么整个进程会被阻塞，而同时，服务端会“监视”全部select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操做，将数据从操做系统拷贝到用户进程。

这个图和blocking I/O(阻塞I/O)的图其实并无太大的不一样，事实上还更差一些。由于这里须要使用两个系统调用(select和recvfrom)，而blocking I/O只调用了一个系统调用(recvfrom)。可是，用select的优点在于它能够同时处理多个链接。

注意：

  1. 若是处理的链接数不是很高的话，使用select/poll的web server不必定比使用multi-threading + blocking I/O的web server性能更好，可能延迟还更大。select/poll的优点并非对于单个链接能处理得更快，而是在于能处理更多的链接。

  2. 在多路复用模型中，对于每个socket，通常都设置成为non-blocking，可是，如上图所示，整个用户的process实际上是一直被block的。只不过process是被select这个函数block，而不是被socket I/O给block。

结论: select的优点在于能够处理多个链接，不适用于单个链接

4.1 select网络I/O模型

#服务端
import socket
import select

server = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
server.bind(('127.0.0.1',8080))
server.listen()
server.setblocking(False)#设置socket的接口为非阻塞,只要没人连服务端就报错

re_lis = [server]
while True:
    r_lis,w_lis,x_lis = select.select(re_lis,[],[])
    for i in r_lis:
        if i == server:
            conn,addr = server.accept()
            re_lis.append(conn)
         else:
            try:
                msg = conn.recv(1024)
                if msg == b'':
                    conn.close()
                    re_lis.remove(conn)
                    continue
                print(msg)
                conn.send(b'byebye')
             except:pass
#客户端
import socket
import time
from threading import thread
def action():
    while True:
        client = socket.socket()
        client.connect(('127.0.0.1',8080))
        client.send(b'hello')
        time.sleep(2)
        client.recv(1024)
        print(msg)
        client.close()
            
for i in range(20):
    t  = thread(target=action)
    t.start()

4.2 epoll模型

select只在windows系统下用

pool能够在windows，linux下用

epoll只在linux下用

select/pool这两种机制，用法都是同样的：
但实际上这两种方法虽然都是能够解决咱们的阻塞，因为这两种方法也都是利用了轮询的方式去处理阻塞的问题，因此当有不少个用户同时来访问服务端的时候，可能我第一个链接对象没有给我发送请求的时候，我顺延的执行了第二个链接对象的而请求，而后一直顺延下去，当有10000个链接对象的话，我就要等到10000个链接对象都执行完了，我才能回过头去处理第一个链接队形的请求
因此select和pool这种方法都由于轮询的缘由形成了执行任务的效率下降

epoll模型因为它只能在linux下才能用，因此对咱们python来讲是比较惋惜的可是咱们python中也有一种机制叫作selectors 它能够帮咱们自动选择该用那种模型，它其实是经过回调函数来解决的

5、信号驱动I/O模型（了解）

以买票的例子举例，该模型小结为：

# 老王去火车站买票，给售票员留下电话，有票后，售票员电话通知老王，而后老王去火车站交钱领票。

# 耗费：往返车站2次，路上2小时，免黄牛费100元，无需打电话

188-大白话五种IO模型-07.png?x-oss-process=style/watermark

因为信号驱动I/O在实际中并不经常使用，因此咱们只作简单了解。

信号驱动I/O模型，应用进程告诉内核：当数据报准备好的时候，给我发送一个信号，对SIGI/O信号进行捕捉，而且调用个人信号处理函数来获取数据报。

6、异步I/O模型

以买票的例子举例，该模型小结为：

# 老王去火车站买票，给售票员留下电话，有票后，售票员电话通知老王并快递送票上门。

# 耗费：往返车站1次，路上1小时，免黄牛费100元，无需打电话

Linux下的asynchronous I/O其实用得很少，从内核2.6版本才开始引入。先看一下它的流程：

188-大白话五种IO模型-05.png?x-oss-process=style/watermark

用户进程发起read操做以后，马上就能够开始去作其它的事。而另外一方面，从kernel的角度，当它受到一个asynchronous read以后，首先它会马上返回，因此不会对用户进程产生任何block。而后，kernel会等待数据准备完成，而后将数据拷贝到用户内存，当这一切都完成以后，kernel会给用户进程发送一个signal，告诉它read操做完成了。

7、I/O模型比较分析

阻塞 vs 非阻塞:

调用 阻塞I/O 会一直block住对应的进程直到操做完成，

非阻塞I/O 在kernel还准备数据的状况下会马上返回。

同步I/O 和 异步I/O 的区别:

定义：

同步I/O操做数/O n致使请求进程被阻塞，直到I/O操做数/O n完成为止;

异步I/O操做数/O n不会致使请求进程被阻塞;

区别：

同步I/O 作”I/O operatI/O n”的时候会将process阻塞，按照这个定义，四个I/O模型能够分为两大类，以前所述的 阻塞I/O ， 非阻塞I/O ，I/O多路复用 都属于 同步I/O 这一类，而 异步I/O 属于后一类。

有人可能会说， 非阻塞I/O 并无被block啊。这里有个很是“狡猾”的地方，定义中所指的”I/O operatI/O n”是指真实的I/O操做，就是例子中的recvfrom这个system call。 非阻塞I/O 在执行recvfrom这个system call的时候，若是kernel的数据没有准备好，这时候不会block进程。可是，当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被block了，在这段时间内，进程是被block的。

异步I/O ：当进程发起I/O操做以后，就直接返回不再理睬了，直到kernel发送一个信号，告诉进程说I/O完成。在这整个过程当中，进程彻底没有被block。

各个I/O Model的比较如图所示：

188-大白话五种IO模型-06.png?x-oss-process=style/watermark

通过上面的介绍，会发现 非阻塞I/O 和 异步I/O 的区别仍是很明显的。在非阻塞I/O 中，虽然进程大部分时间都不会被block，可是它仍然要求进程去主动的check，而且当数据准备完成之后，也须要进程主动的再次调用recvfrom来将数据拷贝到用户内存。而 异步I/O 则彻底不一样。它就像是用户进程将整个I/O操做交给了他人（kernel）完成，而后他人作完后发信号通知。在此期间，用户进程不须要去检查I/O操做的状态，也不须要主动的去拷贝数据。

能够看出，以上五个模型的阻塞程度由低到高为：阻塞I/O>非阻塞I/O>多路转接I/O>信号驱动I/O>异步I/O，所以他们的效率是由低到高的。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程