《深入浅出nodejs》读书笔记（2）
概述
本来是想着学学node.js试试的，后来发现node.js才是真正的js啊，它里面用到了很多我们平时没用过的js特性，而且还非常优雅，比如它里面的异步编程思想，总之，《深入浅出node.js》绝对值得一看。
下面是我的读书笔记。
异步IO
1.异步IO的优势：a.从用户体验上来说，异步IO在这个资源的获取时并不会阻塞下一个资源，因此我们可以享受并发的体验；b.从资源分配上来说，单线程同步编程模型会因阻塞IO导致硬件资源得不到更优的使用，多线程编程模型会因为死锁、状态同步等问题让开发人员头疼，但是异步IO利用单线程，远离了死锁和状态同步等问题，而且利用子进程也弥补了无法利用多核CPU的缺点。
2.阻塞IO会造成CPU等待IO，浪费等待时间；非阻塞性IO返回后，CPU的时间片可以用来处理其他事务，但是应用程序需要重复调用IO操作来确认是否完成。这种判断操作叫做轮询。
3.现存的轮询技术主要有：
- read。重复调用来检查IO的状态。
- select。通过文件描述符的事件状态来进行判断。
- poll。采用链表的方式避免数组长度的限制。
- epoll。进入轮询的时候如果没有检查到IO事件，将会进行休眠。
- kqueue。仅在FreeBSD系统下存在。
4.理想的完美异步IO：应用程序发起非阻塞调用，无须通过遍历或者事件唤醒等方式轮询，可以直接处理下一个任务，只需在IO完成后通过信号或者回调将数据传递给应用程序。
5.现实的异步IO：利用多线程解决。让一个线程进行计算处理，通过线程之间的通信将IO得到的数据进行传递，这就轻松实现了异步IO。
6.由于windows平台和lunix等平台的差异，Node提供了libuv作为抽象封装层，使得所有平台兼容性的判断都由这一层来完成。
7.Node的异步IO：完成整个异步IO环节的有事件循环、观察者和请求对象等。
- 事件循环：每个循环称为Tick，每个Tick的过程查看是否有事件待处理，有就处理，没有就进入下个Tick。
- 观察者：每个事件循环中有一个或多个观察者，判断是否有事件处理的过程就是向这些观察者询问是否有要处理的事件。
- 请求对象：调用过程中，会创建一个FSReqWrap请求对象，来挂载js层传入的参数，并提供调用方法。
- 线程池：组装好请求对象后，会将它送入IO线程池等待执行。执行完毕之后，会通知当前对象操作已经完成，然后执行回调，归还线程池。
8.非IO的异步API：
- setTimeout和setInterval。
- process.nextTick。
- setImmediate。
9.服务器模型：
1.同步式。一次只能处理一个请求，并且其余请求都处于等待状态。
2.每进程/每请求。为每个请求启动一个进程。（不具备扩展能力，因为系统资源只有那么多）
3.每线程/每请求。为每个请求启动一个线程。(由于每个线程都占用一定内存，并发过多时内存容易被用光)
4.事件驱动。无须为每一个请求创建额外的对应线程，可以省掉创建线程和销毁线程的开销，上下文切换的代价也很低。
