《深入浅出node.js》一:异步I/O
近期从图书馆借来《深入浅出node.js》一书，拜读ing，今天晚上阅读了“异步I/O”一章。简要梳理一下：
I/O的阻塞与非阻塞
阻塞I/O完成整个获取数据的过程，而非阻塞I/O则不带数据直接返回，要获取数据，还需要通过文件描述符再次读取。
I/O的同步与异步
I/O的同步与异步出现在应用程序中。如果做阻塞I/O调用，应用程序等待调用的完成的过程就是一种同步状况。相反，I/O为非阻塞模式时，应用程序则是异步的。
异步I/O与轮询技术
当进行非阻塞I/O调用时，要读到完整的数据，应用程序需要进行多次轮询，才能确保读取数据完成，以进行下一步的操作。 轮询技术的缺点在于应用程序要主动调用，会造成占用较多CPU时间片，性能较为低下。现存的轮询技术有以下这些：
- read：通过重复调用来检查I/O状态，是最原始性能最低的一种方式
- select：对read的改进，通过对文件描述符上的事件状态来进行判断。缺点是文件描述符最大的数量有限制
- poll：对select的改进，采用链表的方式避免最大数量限制，但描述符较多时，性能还是十分低下
- epoll：进入轮询时若没有检查到I/O事件，将会进行休眠，直到事件发生将其唤醒。这是当前Linux下效率最高的I/O事件通知机制
注：select 和epoll机制，在《tcp/ip网络编程》相关文章中已经介绍。
轮询满足了非阻塞I/O确保获取完整数据的需求，但对于应用程序而言，它仍然只能算作一种同步，因为依然需要等待I/O完全返回。等待期间，CPU要么用于遍历文件描述符的状态，要么用于休眠等待事件发生。
理想的异步I/O模型
理想的异步I/O应该是应用程序发起异步调用，而不需要进行轮询，进而处理下一个任务，只需在I/O完成后通过信号或是回调将数据传递给应用程序即可。 
Node的异步I/O
事件循环
Node的执行模型实际上是事件循环。在进程启动时，Node会创建一个无限循环，每一次执行循环体的过程成为一次Tick。每个Tick过程就是查看是否有事件等待处理，如果有则取出事件及其相关的回调函数，若存在关联的回调函数则执行它们，然后进入下一个循环。如果不再有事件处理，就退出进程。
事件循环是一个典型的生产者/消费者模型。异步I/O、网络请求等则是事件的生产者，源源不断为Node提供不同类型的事件，这些事件被传递到对应的观察者那里，事件循环则从观察者那里取出事件并处理。
观察者
每个事件循环中有若干个观察者，通过向这些观察者询问来判断是否有事件要处理。事件循环是一个典型的生产者/消费者模型。在Node中，事件主要来源于网络请求、文件I/O等，这些事件有对应的网络I/O观察者、文件I/O观察者等，事件循环则从观察者那里取出事件并处理。
请求对象
从Javascript发起调用到内核执行完I/O操作的过渡过程中，存在一种中间产物，叫做请求对象。以最简单的Windows下fs.open()方法（根据指定路径和参数去打开一个文件并得到一个文件描述符）为例，从JS调用到内建模块通过libuv进行系统调用，实际上是调用了uv_fs_open()方法。在调用过程中，创建了一个FSReqWrap请求对象，从JS层传入的参数和方法都封装在这个请求对象中，其中我们最为关注的回调函数被设置在这个对象的oncompete_sym属性上。对象包装完毕后，将FSReqWrap对象推入线程池中等待执行。 至此，JS调用立即返回，JS线程可以继续执行后续操作。当前的I/O操作在线程池中等待执行，这就完成了异步调用的第一阶段。
执行回调
回调通知是异步I/O的第二阶段。线程池中的I/O操作调用完毕后，会将获取的结果储存起来，然后通知IOCP当前对象操作已完成，并将线程归还线程池。在每次Tick的执行中，事件循环的I/O观察者会调用相关的方法检查线程池中是否有执行完的请求，如果存在，会将请求对象加入到I/O观察者的队列中，然后将其当做事件处理。 
在最后需要指出： Node通过事件驱动方式处理请求，可以省掉创建和销毁线程的开销，同时操作系统在调度任务时因为线程较少，上下文切换的代价也很低。即使在大量连接的情况下，Node也能有条不紊地处理请求。