IO模型

目录

• IO模型
  • 阻塞IO模型
  • 非阻塞IO
  • 多路复用IO
  • 异步IO

IO模型

在了解IO模型之前呢，我们学过了同步异步，阻塞和非阻塞，IO发生的时候涉及的对象和步骤，我们以tcp并发来解释一下，，他会涉及到两个系统对象，一个是调用IO的process，还有一个就是系统的操作，当它发生的时候，会有两个阶段，等待数据住准备和将数据拷贝到进程中

阻塞IO模型

当系统调用的recvfrom的这个系统调用，就开始了第一个IO阶段，准备数据，但是network IO来说，i很多时候数据在一开始还没有到达，这个时候kernel就要开始等待足够的数据到来，但是用户进程这边整个进程都会被阻塞，等kernel一直等到数据准备号，他就会将数据从kernel中拷贝到内存中，然后kernel返回结果，用户进程才接触block的状态，重新运行起来

所以blocking io的特点就是在io执行的两个阶段就被block了

以tcp作业为例，所有的io接口都是阻塞的，如accept 和recv，在此期间线程将无法执行任何的网络请求

解决方案：

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

方案存在的问题：

开启多线程的方式，在遇到同时响应成千上百的链接请求，无论是多线程还是多进程都会严重呢个占用系统资源，降低系统对外界响应的效率，而且线程和进程本身也该呢个容易有进入假死状态

改进方案：

这个时候我们可能考虑到了线程池，减少创建和销毁线程的频率，维持一定合理的数量的线程，并让空闲的线程重新承担执行任务，线程池和连接池都可以很好的降低系统的开销

改进后的问题：

使用了线程池和连接池技术上也只是在一定程度上缓解频繁调用io接口带来的资源占用，而且池子也是有上限的，当请求大大超过上线的时候，池子 构成的系统对外界的响应并不比池子的时候效果好多少，所以使用池子必须考虑面临的响应规模，斌且根据响应的规模调整池子的大小，这个时候呢，我们可以考虑非阻塞io

非阻塞IO

当用户进程发出read操作时，如果kernel中的数据骄傲没有准备好，那么它并不会block用户进程，二十立刻返回一个error。从用户进程角度来说，他发起一个read操作后，并不需要等待，而是马上就得到了一个结果，用户进程判断结果是一个error时，他就知道数据还没有准备好，于是用户就可以在本次到下次再发起read询问的时间间隔内做其他事情，或者直接在此发送read操作，一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call， 那么他马上就会将数据拷贝到内存中，然后返回

也就是说非阻塞recvfrom系统调用之后，进程并没有被阻塞，内核马上返回给进程，如果数据还没准备好，此时会返回一个error，进程在返回之后，还可以干点别的时候，然后再发起recvfrom系统调用，重复上面的过程，循环往复的进程recvfrom系统调用，这个过程叫轮询，轮询检查内核的数据，知道数据准备好，再拷贝到进程，进程数据处理，需要注意的时拷贝数据的整个过程，进程属于阻塞状态。

我们来看一下例子

# 服务端
import socket
import time

server=socket.socket()
server.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)
server.bind(('127.0.0.1',8083))
server.listen(5)

server.setblocking(False)
r_list=[]
w_list={}

while 1:
    try:
        conn,addr=server.accept()
        r_list.append(conn)
    except BlockingIOError:
        # 强调强调强调：！！！非阻塞IO的精髓在于完全没有阻塞！！！
        # time.sleep(0.5) # 打开该行注释纯属为了方便查看效果
        print('在做其他的事情')
        print('rlist: ',len(r_list))
        print('wlist: ',len(w_list))


        # 遍历读列表，依次取出套接字读取内容
        del_rlist=[]
        for conn in r_list:
            try:
                data=conn.recv(1024)
                if not data:
                    conn.close()
                    del_rlist.append(conn)
                    continue
                w_list[conn]=data.upper()
            except BlockingIOError: # 没有收成功，则继续检索下一个套接字的接收
                continue
            except ConnectionResetError: # 当前套接字出异常，则关闭，然后加入删除列表，等待被清除
                conn.close()
                del_rlist.append(conn)


        # 遍历写列表，依次取出套接字发送内容
        del_wlist=[]
        for conn,data in w_list.items():
            try:
                conn.send(data)
                del_wlist.append(conn)
            except BlockingIOError:
                continue


        # 清理无用的套接字,无需再监听它们的IO操作
        for conn in del_rlist:
            r_list.remove(conn)

        for conn in del_wlist:
            w_list.pop(conn)



#客户端
import socket
import os

client=socket.socket()
client.connect(('127.0.0.1',8083))

while 1:
    res=('%s hello' %os.getpid()).encode('utf-8')
    client.send(res)
    data=client.recv(1024)

    print(data.decode('utf-8'))

是不是非阻塞就可以解决我们的问题，答案是不

缺点：

# 循环调用recv将大幅度占用cpu，这条是我们在代码中time.sleep(2)的原因，否则在低配置的主机下容易出现卡机的情况

# 任务完成的响应延迟增大了，每过一段时间才去轮询read操作，而任务可能在两次轮询之间的任意时间完成，这个会导致整个数据吞吐量的降低

这个方案中的recv()更多的是起到检测‘操作是否完成’的作用，实际操作系统提供了一些更为高效的检测‘操作是否完成’作用的接口，select多路复用模式，可以一次检测多个链接是否活跃

多路复用IO

当用户调用select，那么整个进程会被block，而同时，kernel会监听所有的select负责socket，当任何一个socket中的数据准备好了，select就会返回，这个时候用户进程在调用read操作的，将数据从kernel拷贝到用户进程。

这个图和blocking IO的图其实并没有太大的不同，事实上还更差一些。因为这里需要使用两个系统调用(select和recvfrom)，而blocking IO只调用了一个系统调用(recvfrom)。但是，用select的优势在于它可以同时处理多个connection。

强调：

• 如果处理的链接数不是很高的话，使用select不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟会更大，select的优势并不是对于单个链接能处理的更快，二十在于能处理更多的链接

• 在多路复用模型中，对于每一个socket，一般都设置成为non-blocking，但是，如图所示，整个用户的process其实就是一直被block的。只不过process是被select这个函数block，而不是被socket io给block

  结论：select的优势在于可以处理多个链接，不适用于单个链接

#服务端
from socket import *
import select
server = socket(AF_INET, SOCK_STREAM)
server.bind(('127.0.0.1',8093))
server.listen(5)
server.setblocking(False)
print('starting...')

rlist=[server,]
wlist=[]
wdata={}

while True:
    rl,wl,xl=select.select(rlist,wlist,[],0.5)
    print(wl)
    for sock in rl:
        if sock == server:
            conn,addr=sock.accept()
            rlist.append(conn)
        else:
            try:
                data=sock.recv(1024)
                if not data:
                    sock.close()
                    rlist.remove(sock)
                    continue
                wlist.append(sock)
                wdata[sock]=data.upper()
            except Exception:
                sock.close()
                rlist.remove(sock)

    for sock in wl:
        sock.send(wdata[sock])
        wlist.remove(sock)
        wdata.pop(sock)

#客户端
from socket import *

client=socket(AF_INET,SOCK_STREAM)
client.connect(('127.0.0.1',8093))


while True:
    msg=input('>>: ').strip()
    if not msg:continue
    client.send(msg.encode('utf-8'))
    data=client.recv(1024)
    print(data.decode('utf-8'))

client.close()

select监听fd变化的过程分析

用户进程创建socket对象，拷贝监听的fd到内核空间，每一个fd会对应一张系统文件表，内核空间的fd响应到数据后，就会发送信号给用户进程数据已到；
用户进程再发送系统调用，比如（accept）将内核空间的数据copy到用户空间，同时作为接受数据端内核空间的数据清除，这样重新监听时fd再有新的数据又可以响应到了（发送端因为基于TCP协议所以需要收到应答后才会清除）。

该模型的优点：

相比其他模型，使用select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU，同时能够为多客户端提供服务。如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值。

该模型的缺点：

首先select()接口并不是实现“事件驱动”的最好选择。因为当需要探测的句柄值较大时，select()接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如linux提供了epoll，BSD提供了kqueue，Solaris提供了/dev/poll，…。如果需要实现更高效的服务器程序，类似epoll这样的接口更被推荐。遗憾的是不同的操作系统特供的epoll接口有很大差异，所以使用类似于epoll的接口实现具有较好跨平台能力的服务器会比较困难。
其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的。

异步IO

异步IO通过异步提交任务 + 回调机制的方式降低阻塞等待时间。

• 原理：任务异步替提交后，不做任何等待，直接处理其他任务。相当于，我向中介找房子，中介接到任务后开始等待房源；等房源到了之后他自己主动先去看房，看房结束后，主动告诉我说好了可以去住了。
• 操作系统收到数据后，主动将数据拷贝给app内存，然后通知app说数据好了，app不经历 copy data阻塞阶段。
• 异步IO，应用程序不经历 wait data 和 copy data 两个阻塞阶段。
• 优点：异步IO模型是所有模型中效率最高的，也是使用最广泛的

总结：

• 阻塞IO， 经历两个阻塞阶段，可以用多线程（进程）实现小规模并发
• 非阻塞IO，经历一个阻塞阶段，死循环严重消耗CPU资源，不推荐
• 多路复用IO，经历一个阻塞阶段，通过监管机制，实现单线程内中等规模并发
• 异步IO，不经历阻塞阶段，异步加回调机制，实现大规模高并发