我们以网络请求IO为例,首先介绍服务端处理一次完整的网络IO请求的典型流程:
应用程序获得一个 *** 作结果,通常包括两个不同的阶段:
等待数据准备好
- 从内核向进程复制数据
以下,我们以 recvfrom
函数为例,解释说明各种IO模型
阻塞调用是指调用结果返回之前,当前线程会被挂起,调用线程只有在等待系统内核层面所有 *** 作完成之后,调用才会结束。
阻塞I/O造成了cpu的等待I/O,浪费了CPU的时间片。
非阻塞式I/O模型(non-blocking I/O)相比于前者,非阻塞I/O不带数据直接返回,要获取数据,还需要通过文件描述符再次尝试读取数据
非阻塞调用得到返回(并不是真实的期待数据)之后,CPU时间片可以用于处理其他的事情,可以明显提升性能。
但是随之而来的问题是,之前的 *** 作并不是一次完整的I/O,返回得到的结果不是期望得到的业务数据,而仅仅是异步调用状态。
为了获取完整的数据,应用程序需要重复调用IO *** 作来确认 *** 作是否已经完成,这种 *** 作我们称之为轮询,常见的几种轮询策略如下
忙轮询这是最原始,也是性能最低的一种方式,通过重复调用来检查I/O状态达到获取完整数据的目的
优点:编程简单
缺点:CPU一直耗费在轮询上,同时影响服务器性能,因为你轮询之后服务器还要进行作答
I/O复用模型(I/O multiplexing)在 I/O 复用模型中,会用到 Select 或 Poll 函数或 Epoll 函数(Linux 2.6 以后的内核开始支持),这两个函数也会使进程阻塞,但是和阻塞 I/O 有所不同。
这三个函数可以同时阻塞多个 I/O *** 作,而且可以同时对多个读 *** 作,多个写 *** 作的 I/O 函数进行检测,直到有数据可读或可写时,才真正调用 I/O *** 作函数。
三种I/O复用机制的区别如下
select
由于select采用1024长度的数组来存储文件状态,因此最多可以同时检测1024个文件描述符
poll
相比select略有改进,采用链表避免了1024的长度限制,并且能避免不需要的遍历检查,相比select性能稍有改善
epoll/kqueue
是linux下效率最高的I/O事件通知机制,轮询时如果没有检测到I/O事件,将会进行休眠,直到事件发生将线程唤醒。它是真正利用了事件通知,执行回调,而不是遍历(文件描述符)查询,因此不会浪费CPU
小结:本质上说,轮询仍然是一种同步 *** 作,因为应用程序仍然在等待I/O完全返回,等待期间要么遍历文件描述状态,要么休眠等待事件的发生。
信号驱动式I/O模型(signal-driven I/O)在信号驱动式 I/O 模型中,应用程序使用信号驱动 I/O,并安装一个信号处理函数,进程继续运行并不阻塞。
当数据准备好时,程序会收到一个 SIGIO 信号,可以在信号处理函数中调用 I/O *** 作函数处理数据。
小结:到此为止,信号驱动式I/O模型是更加符合我们的异步需求的,程序会在等待数据的过程中异步执行其他的业务逻辑。
但是!!! 在数据从内核复制到用户空间过程中依然是阻塞的,并不能算是一场彻底的革命(异步)。
理想中的(Node)非阻塞异步I/O我们理想中的异步I/O应该是应用程序发起非阻塞调用,无需通过轮询的方式进行数据获取,更没有必要在数据拷贝阶段进行无谓的等待,而是能够在I/O完成之后,通过信号或者回调函数的方式传递给应用程序,在此期间应用程序可以执行其他业务逻辑。
实际的异步I/O实际上,linux平台下原生支持了异步I/O(AIO),但是目前 AIO 并不完善,因此在 Linux 下实现高并发网络编程时都是以 I/O 复用模型为主。
而Windows 下通过 IOCP 实现了真正的异步 I/O。
多线程模拟异步I/Olinux平台下,Node利用线程池,通过让部分线程进行阻塞I/O或者非阻塞I/O+轮询的方式完成数据获取,让某一个单独的线程进行计算,通过线程之间的通信,将I/O结果进行传递,这样便实现了异步I/O的模拟。
其实Windows平台下的IOCP异步异步方案底层也是采用线程池的方式实现的,所不同的是,后者的线程池是由系统内核进行托管的。
我们常说Node是单线程的,但其实只能说是JS执行在单线程中,无论是*nix还是windows平台,底层都是利用线程池来完成I/O *** 作。
更多node相关知识,请访问:nodejs 教程!
以上就是聊聊Node中的各种I/O模型的详细内容,
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)