标签：
Nginx是以事件驱动的，也就是说Nginx内部流程的向前推进基本都是靠各种事件的触发来驱动，否则Nginx将一直阻塞在函数epoll_wait（）或suspend函数，Nginx事件一般分为I/O事件和定时事件,当一个事件到来后，监听FD的工作进程就开始处理事件，并执行回调函数，开始处理与响应。
I/O多路复制机制，Nginx封装了各种系统平台下的I/O事件处理机制，使得在跨平台时高效运行。下图列举了一些常见的I/O事件处理机制:
上图中，epoll模型是目前最高效的机制，它相比与select模型而言，最大的好处是不会随着被监控描述符数目的增加而导致效率急速下降。select模型是采用遍历扫描来判断每个描述符是否有事件发生，当监控的描述符数目越多，自然好事越大，而且由于受系统默认限制，select模型最多只能同时监控1024个描述符。相反，epoll模型同时监控的描述符个数不受限制；其次，epoll模型对事件的响应是触发式的，也即无需扫描，而只需对有事件发生的描述符做处理。epoll模型有两种触发方式，水平触发和边缘触发。
水平触发：支持阻塞和非阻塞状态，当描述符从未就绪变为就绪时，内核通过epoll告诉进程该描述符有事件发生，之后如果进程一直不对这个就绪状态做出任何操作，则内核会持续通知，知道事件处理完成。
边缘触发：高速工作方式（只支持非阻塞），当描述符从未就绪变为就绪时，内核通过epoll告诉进程该描述符有事件发生，之后就算进程一直不对这个就绪状态
说到I/O复用，自然有另一个问题，那就是负载均衡，如何调度进程。在一般情况下，配置Nginx执行时，工作进程都会有多个，由于各个工作进程相互独立的接受客户端请求、处理、响应，所以就可能会出现负载不均衡的情况，比如极端情况可能会是1个工作进程当前有3000个请求等待处理；而另一个进程当前却只有300个请求等待处理，这时候就设计到I/O负载均衡。如果进程并没有处于过载状态，那么就会去争用锁（争用套接字的控制权），如果争锁成功，就会把争取到的套接字加入自己的监控机制里，争锁失败就会把监听套接口从自己的监听事件中去掉。此时设置的监控机制的阻塞点的超时时间限制在一个比较短的范围内，超时更快，那么就更频繁的从阻塞中跳出来，也即有更多的机会去争抢互斥锁。当进程过载时，所做的工作就是计数，使ngx_accept_disabled减1，知道为0，那么此进程有可以去争锁。拥有锁的进程必须尽量缩短自身持锁时间，以让其他进程拥有更多机会。
如果在处理新建连接事件的过程中，在监听套接口上又来了新的请求，此时此新的请求只有等到下次被进程争取倒锁并被加入监控机制中时才会被抓取出来。在同一时刻，监听套接口只能被一个进程监控，但是可以被多个进程拥有。
标签：
原文地址：http://www.cnblogs.com/hitwhhw09/p/4611217.html
