深刻浅出node(3) 异步I/O

这篇主要整理深刻浅出Node.js第三章 异步I/Ojavascript

一) 异步I/O的缘由 java

二)异步I/O实现现状node

  2.1 异步I/O与非阻塞I/O浏览器

  2.2 轮询服务器

  2.3 理想的非阻塞异步I/O多线程

  2.4 现实的异步I/O并发

三)Node的异步I/O异步

  3.1 事件循环ide

  3.2 理解异步回调函数的执行过程函数

    3.2.1 基础

    3.2.2 过程

四)事件驱动与高性能服务器

 

一) 异步I/O的缘由  异步I/O主要有如下两点的需求

  • 用户体验  同步的模式下,在浏览器中等待服务端数据的过程当中,浏览器页面会锁死   同时请求A B   同步的状况下时间为 time(A) + time(B)  异步的状况下是 时间为 Max(time(A),time(B))  而且当请求不断增加的时候,带来的差别更大
  • 异步I/O能更好的分配资源 异步I/O不会阻塞后续的运算,将原有的等待I/O的时间分配给其他的任务去执行

二) 异步I/O实现现状

  2.1 异步I/O与非阻塞I/O   对操做系统的内核来讲只存在阻塞I/O和非阻塞I/O (我对书中这部分的理解是这样的 好比异步I/O是node为咱们提供的一层API接口,让咱们能经过非阻塞的形式去I/O)  

  操做系统对输入输出设备抽象成文件,内核在进行文件的I/O操做的时候,经过文件描述符进行管理,也就是应用程序须要I/O的时候,须要先打开文件描述符,在根据文件描述符去实现文件的读写  非阻塞I/O和阻塞I/O的区别主要在于阻塞I/O直接完成整个数据获取的流程,非阻塞I/O返回的是文件描述符,当须要获取数据的时候,在经过文件描述符去读取数据

  2.2 轮询 轮询技术主要为了解决非阻塞I/O什么时候完成完整的I/O而出现的  下面是轮询技术的演变过程

  • read 它经过重复检查I/O的状态来完成完整数据的读取 在获得数据前 CPU一直处于等待的状态

  • select 它在read的基础上进行了一些改进,经过对文件描述符的事件状态进行判断来完成数据的I/O  它采用一个1024长度的数据来存储状态,因此它只能同时检测1024个文件描述符

  • poll 它是在select基础上进行的改进,它采用链表的方式存储文件描述符,避免了数据的限制,可是在文件描述符不少的时候,性能有所降低

 

  • epoll  该方案是Linux下最高的事件通知机制 当没有I/O事件的时候,它会休眠(观察者),充分的利用了事件通知,执行回调来代替遍历查询 不会浪费CPU 因此执行的效率更高

  2.3 理想的非阻塞异步I/O  理想的应该是由应用程序发起异步方法,不须要遍历或者事件唤醒等方式轮询,直接进入下一个任务,在I/O完成后经过信号或者回调的方式将数据传送给应用程序

  2.4 现实的异步I/O

三) Node中的异步I/O

  3.1 事件循环  在进程启动的时候,Node会建立一个相似于while(true)的循环,每执行一次循环体称为Tick,每一次Tick的时候会查看是否有事件等待处理,若是有就取出事件而且执行相应的回调函数,没有的话就退出进程  事件循环是典型的生产者消费者模型 在Windows下这个循环基于IOCP,而在*nix基于多线程建立

 3.2 理解异步回调的执行过程

  3.2.1 基础 

  • 请求对象   从javascript发起调用到内核执行完I/O操做的过渡过程当中的中间产物 全部的状态都保存在这个对象,包括送入线程池等待执行以及I/O操做完毕后的回调处理 
  •  Node中的经典调用模式 javascript调用Node的核心模块,核心模块调用C++内建模块 内建模块经过libuv(跨平台)进行系统调用

  3.2.2 过程  

  1. 从javascript到内建模块的调用过程当中会建立一个请求对象,将javascript层传入的参数和方法都封装到这个请求对象上,回调函数会被设置到这个请求对象的oncomplete_sym上 ,供后续的调用,而后将这个请求对象推入线程池中等待执行,此时javascript的调用当即返回(底层的I/O仍然多是阻塞或者是非阻塞的)
  2. 线程池中的I/O执行完毕后,会将结果存储在请求对象的result上,此时它会通知自己的执行状态已经完毕,而且将线程归还给线程池
  3. 在每次的Tick中,检查是否有执行完的请求,若是有将请求对象加入I/O观察者的队列,而且当作事件进行处理
  4. I/O观察者会取出事件回调函数而且将result当作参数传递给回调函数执行,这样就达到了执行回调函数的目的  

四)事件驱动与高性能服务器

  几种经典的服务器模型

  • 同步式 一次只能处理一个请求,而且其他的请求都处于等待的状态
  • 每进程/每请求 为每一个请求启动一个进程,可是不具有扩展性,由于系统的资源只有那么多
  • 每线程/每请求 为每一个请求启动一个线程来处理,可是线程占用必定的内存,大并发到来的时候,会形成系统运行缓慢

 Node的高性能正是由于它的事件驱动模式.

相关文章
相关标签/搜索