“阻塞”与”非阻塞”与”同步”与”异步”不能简单的从字面理解，提供一个从分布式系统角度的回答。

1、同步与异步

同步和异步关注的是消息通信机制 (synchronous communication/ asynchronous communication)所谓同步，就是在发出一个*调用*时，在没有得到结果之前，该*调用*就不返回。但是一旦调用返回，就得到返回值了。换句话说，就是由*调用者*主动等待这个*调用*的结果。而异步则是相反，*调用*在发出之后，这个调用就直接返回了，所以没有返回结果。换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。而是在*调用*发出后，*被调用者*通过状态、通知来通知调用者，或通过回调函数处理这个调用。

典型的异步编程模型比如Node.js

举个通俗的例子：

你打电话问书店老板有没有《分布式系统》这本书，如果是同步通信机制，书店老板会说，你稍等，”我查一下"，然后开始查啊查，等查好了（可能是5秒，也可能是一天）告诉你结果（返回结果）。
而异步通信机制，书店老板直接告诉你我查一下啊，查好了打电话给你，然后直接挂电话了（不返回结果）。然后查好了，他会主动打电话给你。在这里老板通过“回电”这种方式来回调。

2、阻塞与非阻塞

阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态.
阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。
还是上面的例子，你打电话问书店老板有没有《分布式系统》这本书，你如果是阻塞式调用，你会一直把自己“挂起”，直到得到这本书有没有的结果，如果是非阻塞式调用，你不管老板有没有告诉你，你自己先一边去玩了， 当然你也要偶尔过几分钟check一下老板有没有返回结果。在这里阻塞与非阻塞与是否同步异步无关。跟老板通过什么方式回答你结果无关。
如果是关心blocking IO/ asynchronous IO, 参考  Unix Network Programming View Book

老张爱喝茶，废话不说，煮开水。
出场人物：老张，水壶两把（普通水壶，简称水壶；会响的水壶，简称响水壶）。
1）老张把水壶放到火上，立等水开。（同步阻塞）老张觉得自己有点傻
2）老张把水壶放到火上，去客厅看电视，时不时去厨房看看水开没有。（同步非阻塞）老张还是觉得自己有点傻，于是变高端了，买了把会响笛的那种水壶。水开之后，能大声发出嘀~~~~的噪音。
3）老张把响水壶放到火上，立等水开。（异步阻塞）老张觉得这样傻等意义不大
4）老张把响水壶放到火上，去客厅看电视，水壶响之前不再去看它了，响了再去拿壶。（异步非阻塞）
老张觉得自己聪明了。

所谓同步异步，只是对于水壶而言。普通水壶，同步；响水壶，异步。虽然都能干活，但响水壶可以在自己完工之后，提示老张水开了。这是普通水壶所不能及的。同步只能让调用者去轮询自己（情况2种），造成老张效率的低下。

所谓阻塞非阻塞，仅仅对于老张而言。立等的老张，阻塞；看电视的老张，非阻塞。情况1和情况3种老张就是阻塞的，媳妇喊他都不知道。虽然3中响水壶是异步的，可对于立等的老张没有太大的意义。所以一般异步是配合非阻塞使用的，这样才能发挥异步的效用。
-来自知乎：https://www.zhihu.com/question/19732473

I/O模型

由于进程是不可直接访问外部设备的，所以只能调用内核去调用外部的设备(上下文切换)，然后外部设备比如磁盘，读出存储在设备自身的数据传送给内核缓冲区，内核缓冲区在copy数据到用户进程的缓冲区。在外部设备响应的给到用户进程过程中，包含了两个阶段；由于数据响应方式的不同，所以就有了不同的I/O模型。
一共有五种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的性能谁的性能更高，同样十分明了。

I/O模型一般通信流程：

1. 首先我们客户端发送一个请求到nginx，请求首先是到网卡；
2. 网卡将请求交由内核空间的读缓冲区来处理，这是拆包的过程，发现请求的是80端口；
3. 内核便将请求发给用户空间的nginx，nginx解包发现客户端请求的index.html页面；
4. nginx便进行系统调用将请求发给内核;
5. 内核发现在请求的是一页面，便调用磁盘的驱动程序，连接磁盘;这里有DMA(直接内存存取)的过程;
6. 内核通过驱动调用磁盘的index.html文件，并将取得的文件保存在buffer中，便通知ningx或线程取相应页面文件；
7. nginx通过系统调用将内核缓存中的页面文件复制到进程缓存区域中；
8. nginx取得页面文件来响应用户，再次通过系统调用将页面文件发给内核的写buffer；
9. 内核进程页面文件的封装并通过网卡发送出去；
10. 当报文到达网卡时通过网络响应给客户端；

原理图：

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…]，稳定性高。

转载请注明：黑夜 » nginx系列之(一)I/O模型