摘抄自博客园rikewang博客，方便自己查找阅读！！！！
http://www.cnblogs.com/wxl-dede/p/5134636.html
同步异步,阻塞非阻塞 和nginx的IO模型
同步与异步
同步和异步关注的是消息通信机制 (synchronous communication/ asynchronous communication)。所谓同步，就是在发出一个*调用*时，在没有得到结果之前，该*调用*就不返回。但是一旦调用返回，就得到返回值了。换句话说，就是由*调用者*主动等待这个*调用*的结果。而异步则是相反，*调用*在发出之后，这个调用就直接返回了，所以没有返回结果。换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。而是在*调用*发出后，*被调用者*通过状态、通知来通知调用者，或通过回调函数处理这个调用。
典型的异步编程模型比如Node.js
举个通俗的例子：你打电话问书店老板有没有《分布式系统》这本书，如果是同步通信机制，书店老板会说，你稍等，"我查一下"，然后开始查啊查，等查好了（可能是5秒，也可能是一天）告诉你结果（返回结果）。而异步通信机制，书店老板直接告诉你我查一下啊，查好了打电话给你，然后直接挂电话了（不返回结果）。然后查好了，他会主动打电话给你。在这里老板通过"回电"这种方式来回调。
阻塞与非阻塞
阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态.阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。
还是上面的例子，你打电话问书店老板有没有《分布式系统》这本书，你如果是阻塞式调用，你会一直把自己"挂起"，直到得到这本书有没有的结果，如果是非阻塞式调用，你不管老板有没有告诉你，你自己先一边去玩了， 当然你也要偶尔过几分钟check一下老板有没有返回结果。在这里阻塞与非阻塞与是否同步异步无关。跟老板通过什么方式回答你结果无关。
I/O模型
由于进程是不可直接访问外部设备的，所以只能调用内核去调用外部的设备(上下文切换)，然后外部设备比如磁盘，读出存储在设备自身的数据传送给内核缓冲区，内核缓冲区在copy数据到用户进程的缓冲区。在外部设备响应的给到用户进程过程中，包含了两个阶段；由于数据响应方式的不同，所以就有了不同的I/O模型。
一般有五种I/O模型：
阻塞式I/O模型：
默认情况下，所有套接字都是阻塞的。进程挂起，内核等待外部IO响应，IO完成传送数据到kernel buffer，数据再从buffer复制到用户的进程空间
非阻塞式I/O：
在内核请求IO设备响应指令发出后，数据就开始准备，在此期间用户进程没有阻塞，也就是没有挂起，它一值在询问或者check数据有没有传送到kernel buffer中，忙等…。但是第二个阶段（数据从kernel buffer复制到用户进程空间）依然是阻塞的。但这种IO模型会大量的占用CPU的时间，效率很低效，很少使用。
I/O多路复用（select，poll，epoll...）：
在内核请求IO设备响应指令发出后，数据就开始准备，在此期间用户进程是阻塞的。数据从kernel buffer复制到用户进程的过程也是阻塞的。但是和阻塞I/O所不同的是，它可以同时阻塞多个I/O操作，而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数，也就是说一个线程可以响应多个请求。
信号驱动式I/O（事件驱动）
第一阶段是非阻塞的，当数据传送的kernel buffer后，直接用信号的方式通知线程，用的不多
异步I/O:
在整个操作（包括将数据从内核拷贝到用户空间）完成后才通知用户进程
整个的汇总
Nginx中的epoll，poll，select
这三种模式都是属于IO复用模型。
select，poll是主动查询，它们可以同时查询多个fd（文件句柄）的状态，另外select有fd个数的限制，poll没有限制。select和poll不同的是，他们创建的事件描述符不同，select创建读、写、异常三个集合，而poll在一个集合内设定三种描述，由于select和poll每个循环都会检查事件的发生，而poll的事件比较少，性能上比select要好一些；
epoll是基于回调函数的，无轮询。如果当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度，不管哪个Socket是活跃的，都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll(Linux)、kqueue(FreeBSD)、/dev/poll(soloris)做的。举个经典例子，假设你在大学读书，住的宿舍楼有很多间房间，你的朋友要来找你。select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。而epoll版宿管大妈会先记下每位同学的房间号，你的朋友来时，只需告诉你的朋友你住在哪个房间即可，不用亲自带着你的朋友满大楼找人。如果来了10000个人，都要找自己住这栋楼的同学时，select版和epoll版宿管大妈，谁的效率更高，不言自明。同理，在高并发服务器中，轮询I/O是最耗时间的操作之一，select、epoll、/dev/poll的性能谁的性能更高，同样十分明了。
web一般请求流程
-
首先我们客户端发送一个请求到Web服务器，请求首先是到网卡。
-
网卡将请求交由内核空间的内核处理，其实就是拆包了，发现请求的是80端口。
-
内核便将请求发给了在用户空间的Web服务器，Web服务器解包发现客户端请求的index.html页面、
-
Web服务器便进行系统调用将请求发给内核
-
内核发现在请求的是一页面，便调用磁盘的驱动程序，连接磁盘
-
内核通过驱动调用磁盘取得的页面文件
-
内核将取得的页面文件保存在自己的缓存区域中便通知Web进程或线程来取相应的页面文件
-
Web服务器通过系统调用将内核缓存中的页面文件复制到进程缓存区域中
-
Web服务器取得页面文件来响应用户，再次通过系统调用将页面文件发给内核
-
内核进程页面文件的封装并通过网卡发送出去
-
当报文到达网卡时通过网络响应给客户端
Apache和nginx比较：
由于web服务器是一对多的关系，通常完成并行处理的方式有多进程、多线程、异步三种方式。
多进程：多进程就是每个进程对应一个连接来处理请求，进程独立响应自己的请求，一个进程挂了，并不会影响到其他的请求；而且设计简单，不会产生内存泄漏等问题，因此进程比较稳定。但是进程在创建的时候一般是fork机制，会存在内存复制的问题，另外在高并发的情况下，上下文切换将很频繁，这样将消耗很多的性能和时间。早期的apache使用的prework模型就多进程方式，但是apache会预先创建几个进程，等待用户的响应，请求完毕，进程也不会结束。因此性能上有优化很多。
多线程：每个线程响应一个请求，由于线程之间共享进程的数据，所以线程的开销较小，性能就会提高。由于线程管理需要程序自己申请和释放内存，所以当存在内存等问题时，可能会运行很长时间才会暴露问题，所以在一定程度上还不是很稳定。apache的worker模式就是这种方式
异步的方式：nginx的epoll，apache的event也支持，不多说了
Nginx的IO模型是基于事件驱动的，使得应用程序在多个IO句柄间快速切换，实现所谓的异步IO。事件驱动服务器，最适合做的就是IO密集型工作，如反向代理，它在客户端与WEB服务器之间起一个数据中转作用，纯粹是IO操作，自身并不涉及到复杂计算。反向代理用事件驱动来做，显然更好，一个工作进程就可以run了，没有进程、线程管理的开销，CPU、内存消耗都小。
Apache这类应用服务器，一般要跑具体的业务应用，如科学计算、图形图像等。它们很可能是CPU密集型的服务，事件驱动并不合适。例如一个计算耗时2秒，那么这2秒就是完全阻塞的，什么event都没用。想想MySQL如果改成事件驱动会怎么样，一个大型的join或sort就会阻塞住所有客户端。这个时候多进程或线程就体现出优势，每个进程各干各的事，互不阻塞和干扰。当然，现代CPU越来越快，单个计算阻塞的时间可能很小，但只要有阻塞，事件编程就毫无优势。所以进程、线程这类技术，并不会消失，而是与事件机制相辅相成，长期存在。
总的说来，事件驱动适合于IO密集型服务，多进程或线程适合于CPU密集型服务
其实也就是说nginx比较适合做前端代理，或者处理静态文件(尤其高并发情况下)，而apache适合做后端的应用服务器，功能强大[php, rewrite…]，稳定性高。
