回调通知是异步I/O的第二阶段。线程池中的I/O操作调用完毕后，会将获取的结果储存起来，然后通知IOCP当前对象操作已完成，并将线程归还线程池。在每次Tick的执行中，事件循环的I/O观察者会调用相关的方法检查线程池中是否有执行完的请求，如果存在，会将请求对象加入到I/O观察者的队列中，然后将其当做事件处理。
3. 非I/O的异步API
Node中还存在一些与I/O无关的异步API，例如定时器setTimeout()、setInterval()，立即异步执行任务的process.nextTick()和setImmdiate()等，这里略微介绍一下。
3.1 定时器API
setTimeout()和setInterval()浏览器端的API是一致的，它们的实现原理与异步I/O类似，只是不需要I/O线程池的参与。调用定时器API创建的定时器会被插入到定时器观察者内部的一棵红黑树中，每次事件循环的Tick都会从红黑树中迭代取出定时器对象，检查是否超过定时时间，若超过就形成一个事件，回调函数立即被执行。定时器的主要问题在于它的定时时间并非特别精确（毫秒级，在容忍范围内）。
3.2 立即异步执行任务API
在Node出现之前，很多人也许为了立即异步执行一个任务，会这样调用：
复制代码 代码如下:
setTimeout(function() {
// TODO
}, 0);
由于事件循环的特点，定时器的精确度不够，而且采用定时器需要使用红黑树，各种操作时间复杂度为O(log(n))。而process.nextTick()方法只会将回调函数放入队列中，在下一轮Tick时取出执行，复杂度为O(1)更为高效。
此外还有一个setImmediate()方法和上述方法类似，都是将回调函数延迟执行。不过前者的优先级要比后者高，这是因为事件循环对观察者的检查是有先后顺序的。另外，前者的回调函数保存在一个数组中，每轮Tick会将数组中的所有回调函数全部执行完；后者结果保存在链表中，每轮Tick只会执行一个回调函数。
4. 事件驱动与高性能服务器
前面以fs.open()为例阐述了Node如何实现异步I/O。事实上对网络套接字的处理，Node也应用了异步I/O，这也是Node构建Web服务器的基础。经典的服务器模型有：
1.同步式：一次只能处理一个请求，其余请求都处于等待状态
2.每进程/每请求：为每个请求启动一个进程，但系统资源有限，不具备扩展性
3.每线程/每请求：为每个请求启动一个线程。线程比进程要轻量，但每个线程都占用一定内存，当大并发请求到来时，内存很快就会用光
著名的Apache采用的就是每线程/每请求的形式，这也是它难以应对高并发的原因。Node通过事件驱动方式处理请求，可以省掉创建和销毁线程的开销，同时操作系统在调度任务时因为线程较少，上下文切换的代价也很低。即使在大量连接的情况下，Node也能有条不紊地处理请求。
知名服务器Nginx也摒弃了多线程的方式，采用和Node一样的事件驱动方式。如今Nginx大有取代Apache之势。Nginx采用纯C编写，性能较高，但是它仅适合做Web服务器，用于反向代理或负载均衡等。Node可以构建与Nginx相同的功能，也可以处理各种具体业务，自身性能也不错。在实际项目中，我们可以结合它们各自有点，以达到应用的最佳性能。
您可能感兴趣的文章: