Nginx 是如何实现高并发的?
如果一个 server 采用一个进程(或者线程)负责一个 request 的方式，那么进程数就是并发数。那么显而易见的，就是会有很多进程在等待中。等什么?最 多的应该是等待网络传输。其缺点胖友应该也感觉到了，此处不述。
而 Nginx 的异步非阻塞工作方式正是利用了这点等待的时间。在需要等待的 时候，这些进程就空闲出来待命了。因此表现为少数几个进程就解决了大量的 并发问题。
Nginx 是如何利用的呢，简单来说:同样的 4 个进程，如果采用一个进程负 责一个 request 的方式，那么，同时进来 4 个 request 之后，每个进程就 负责其中一个，直至会话关闭。期间，如果有第 5 个 request 进来了。就无 法及时反应了，因为 4 个进程都没干完活呢，因此，一般有个调度进程，每当 新进来了一个 request ，就新开个进程来处理。
Nginx 不这样，每进来一个 request ，会有一个 worker 进程去处理。但不 是全程的处理，处理到什么程度呢?处理到可能发生阻塞的地方，比如向上游 (后端)服务器转发 request ，并等待请求返回。那么，这个处理的 worker 不会这么傻等着，他会在发送完请求后，注册一个事件:“如果 upstream 返 回了，告诉我一声，我再接着干”。于是他就休息去了。此时，如果再有 request 进来，他就可以很快再按这种方式处理。而一旦上游服务器返回了，就会触发这个事件，worker 才会来接手，这个 request 才会接着往下走。
这就是为什么说，Nginx 基于事件模型。
由于 web server 的工作性质决定了每个 request 的大部份生命都是在网络 传输中，实际上花费在 server 机器上的时间片不多。这是几个进程就解决高 并发的秘密所在。即:
webserver 刚好属于网络 IO 密集型应用，不算是计算密集型。异步，非阻 塞，使用 epoll ，和大量细节处的优化，也正是 Nginx 之所以然的技术基石。
