IO操作与IO模型

Posted 2020-12-19 zhangchaocoming

目录

• 一 IO操作本质
• 二 IO模型
  • 1. BIO – 阻塞模式I/O
  • 2. NIO – 非阻塞模式I/O
  • 3. IO Multiplexing - I/O多路复用模型
  • 4. AIO – 异步I/O模型
  • 5 select poll 和epoll
• 三 同步I/O与异步I/O
• 四 并发-并行-同步-异步-阻塞-非阻塞
• 五 IO设计模式
  • Reactor模式
  • Proactor模式
  • 对比分析

一 IO操作本质

数据复制的过程中不会消耗CPU

>  1 内存分为内核缓冲区和用户缓冲区
>  # 2 用户的应用程序不能直接操作内核缓冲区，需要将数据从内核拷贝到用户才能使用
>  # 3 而IO操作、网络请求加载到内存的数据一开始是放在内核缓冲区的

二 IO模型

1. BIO – 阻塞模式I/O

---

用户进程从发起请求，到最终拿到数据前，一直挂起等待； 数据会由用户进程完成拷贝

‘‘‘
举个例子：一个人去 商店买一把菜刀，
他到商店问老板有没有菜刀（发起系统调用）
如果有（表示在内核缓冲区有需要的数据）
老板直接把菜刀给买家（从内核缓冲区拷贝到用户缓冲区）
这个过程买家一直在等待

如果没有，商店老板会向工厂下订单（IO操作，等待数据准备好）
工厂把菜刀运给老板（进入到内核缓冲区）
老板把菜刀给买家（从内核缓冲区拷贝到用户缓冲区）
这个过程买家一直在等待
是同步io
‘‘‘

2. NIO – 非阻塞模式I/O

---

用户进程发起请求，如果数据没有准备好，那么立刻告知用户进程未准备好；此时用户进程可选择继续发起请求、或者先去做其他事情，稍后再回来继续发请求，直到被告知数据准备完毕，可以开始接收为止； 数据会由用户进程完成拷贝

‘‘‘
举个例子：一个人去 商店买一把菜刀，
他到商店问老板有没有菜刀（发起系统调用）
老板说没有，在向工厂进货（返回状态）
买家去别地方玩了会，又回来问，菜刀到了么（发起系统调用）
老板说还没有（返回状态）
买家又去玩了会（不断轮询）
最后一次再问，菜刀有了（数据准备好了）
老板把菜刀递给买家（从内核缓冲区拷贝到用户缓冲区）

整个过程轮询+等待：轮询时没有等待，可以做其他事，从内核缓冲区拷贝到用户缓冲区需要等待
是同步io

同一个线程，同一时刻只能监听一个socket，造成浪费，引入io多路复用，同时监听读个socket
‘‘‘

3. IO Multiplexing - I/O多路复用模型

---

‘‘‘
举个例子：多个人去 一个商店买菜刀，
多个人给老板打电话，说我要买菜刀（发起系统调用）
老板把每个人都记录下来（放到select中）
老板去工厂进货（IO操作）
有货了，再挨个通知买到的人，来取刀（通知/返回可读条件）
买家来到商店等待，老板把到给买家（从内核缓冲区拷贝到用户缓冲区）

多路复用：老板可以同时接受很多请求（select模型最大1024个，epoll模型），
但是老板把到给买家这个过程，还需要等待，
是同步io
‘‘‘

4. AIO – 异步I/O模型

---

发起请求立刻得到回复，不用挂起等待； 数据会由内核进程主动完成拷贝

‘‘‘
举个例子：还是买菜刀
现在是网上下单到商店（系统调用）
商店确认（返回）
商店去进货（io操作）
商店收到货把货发个卖家（从内核缓冲区拷贝到用户缓冲区）
买家收到货（指定信号）

整个过程无等待
异步io

AIO框架在windows下使用windows IOCP技术，在Linux下使用epoll多路复用IO技术模拟异步IO

市面上多数的高并发框架，都没有使用异步io而是用的io多路复用，因为io多路复用技术很成熟且稳定，并且在实际的使用过程中，异步io并没有比io多路复用性能提升很多，没有达到很明显的程度
并且，真正的AIO编码难度比io多路复用高很多
‘‘‘

5 select poll 和epoll

---

#  1 select poll 和epoll都是io多路复用技术
select, poll , epoN都是io多路复用的机制。I/O多路复用就是通过一种机 制个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select, poll , epoll本质上都是同步I/O ,因为他们都需要在读写事件就绪后自己负责进行读写， 也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异 步I/O的实现会负责把数据从内核拷贝到用户空间。
# 2 select
select函数监视的文件描述符分3类，分别是writefds、readfds、和 exceptfds。调用后select函数会阻塞，直到有描述副就绪（有数据可读、 可写、或者有except）,或者超时（timeout指定等待时间，如果立即返回 设为null即可），函数返回。当select函数返回后，可以通过遍历fdset,来 找到就绪的描述符。select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个 优点。select的一个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024 ,可以通过修改宏定义甚至重新编译内核的 方式提升这一限制，但是这样也会造成效率的降低。
# 3 poll
不同于select使用三个位图来表示三个fdset的方式，poll使用一个 pollfd的指针实现。pollfd结构包含了要监视的event和发生的event,不再使用select ‘参数-值‘传递的方式。同时，pollfd并没有最大数量限制（但是数量过大后 性能也是会下降）。和select函数一样，poll返回后，需要轮询pollfd来获取就绪的描述符。从上面看，select和poll都需要在返回后，通过遍历文件描述符来获取 已经就绪的socket。事实上，同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降
# 4 epoll
epoll是在linux2.6内核中提出的，是之前的select和poll的增强版本。相对 于select和poll来说，epoll更加灵活，没有描述符限制。epoll使用一个文 件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。
# 5 更好的例子理解
老师检查同学作业，一班50个人，一个一个问，同学，作业写完了没？select，poll
老师检查同学作业，一班50个人，同学写完了主动举手告诉老师，老师去检查 epoll
# 6 总结
在并发高的情况下，连接活跃度不高，epoll比select好，网站http的请求，连了就断掉
并发性不高，同时连接很活跃，select比epoll好，websocket的连接，长连接，游戏开发

三 同步I/O与异步I/O

• 同步I/O
  • 概念：导致请求进程阻塞的I/O操作，直到I/O操作任务完成
  • 类型：BIO、NIO、IO Multiplexing
• 异步I/O
  • 概念：不导致进程阻塞的I/O操作
  • 类型：AIO

注意：

• 同步I/O与异步I/O判断依据是，是否会导致用户进程阻塞
• BIO中socket直接阻塞等待（用户进程主动等待，并在拷贝时也等待）
• NIO中将数据从内核空间拷贝到用户空间时阻塞（用户进程主动询问，并在拷贝时等待）
• IO Multiplexing中select等函数为阻塞、拷贝数据时也阻塞（用户进程主动等待，并在拷贝时也等待）
• AIO中从始至终用户进程都没有阻塞（用户进程是被动的）

四 并发-并行-同步-异步-阻塞-非阻塞

# 1 并发
并发是指一个时间段内，有几个程序在同一个cpu上执行，但是同一时刻，只有一个程序在cpu上运行跑步，鞋带开了，停下跑步，系鞋带
# 2 并行
指任意时刻点上，有多个程序同时运行在多个cpu上跑步，边跑步边听音乐
# 3 同步：
指代码调用io操作时，必须等待io操作完成才返回的调用方式
# 4 异步
异步是指代码调用io操作时，不必等io操作完成就返回调用方式
# 5 阻塞
指调用函数时候，当前线程别挂起
# 6 非阻塞
指调用函数时候，当前线程不会被挂起，而是立即返回
# 区别：
同步和异步是消息通讯的机制
阻塞和非阻塞是函数调用机制

五 IO设计模式

 Reactor模式，基于同步I/O实现
- Proactor模式，基于异步I/O实现

Reactor模式通常采用IO多路复用机制进行具体实现

• kqueue、epoll、poll、select等机制

Proactor模式通常采用OS Asynchronous IO(AIO)的异步机制进行实现

• 前提是对应操作系统支持AIO，比如支持异步IO的linux(不太成熟)、具备IOCP的windows server(非常成熟)

Reactor模式和Proactor模式都是事件驱动，主要实现步骤：

1. 事件注册：将事件与事件处理器进行分离。将事件注册到事件循环中，将事件处理器单独管理起来，记录其与事件的对应关系。
2. 事件监听：启动事件循环，一旦事件已经就绪/完成，就立刻通知事件处理器
3. 事件分发：当收到事件就绪/完成的信号，便立刻激活与之对应的事件处理器
4. 事件处理：在进程/线程/协程中执行事件处理器

使用过程中，用户通常只负责定义事件和事件处理器并将其注册以及一开始的事件循环的启动，这个过程就会是以异步的形式执行任务。

Reactor模式

---

Proactor模式

---

对比分析

---

Reactor模型处理耗时长的操作会造成事件分发的阻塞，影响到后续事件的处理；

Proactor模型实现逻辑复杂；依赖操作系统对异步的支持，目前实现了纯异步操作的操作系统少，实现优秀的如windows IOCP，但由于其windows系统用于服务器的局限性，目前应用范围较小；而Unix/Linux系统对纯异步的支持有限，因而应用事件驱动的主流还是基于select/epoll等实现的reactor模式

Python中：如asyncio、gevent、tornado、twisted等异步模块都是依据事件驱动模型设计，更多的都是使用reactor模型，其中部分也支持proactor模式，当然需要根据当前运行的操作系统环境来进行手动配置