共计 1429 个字符，预计需要花费 4 分钟才能阅读完成。
本文将解说一下内容：
1、Nginx 的过程模型剖析
2、Nginx 实现高并发原理剖析
这篇文章首先会解说一下 Nginx 的过程模型，只有先了解了 Nginx 过程模型，能力深刻了解 Nginx 实现高并发的原理。
1、Nginx 过程模型介绍
Nginx 的过程模型也是采纳 Master/Worker 模式。当 Nginx 启动时，会先创立一个 Master 过程，Master 过程会 fork 出若干个 Worker 子过程（具体是多少个子过程能够在 Nginx 的配置文件中来配置）
Master 过程的作用如下：
Master 过程次要是接管外界信号（如重载配置等），传递给 Worker 过程
监听 Worker 过程的运行状态，负责 Worke 过程的创立和销毁 Worker 过程的作用如下：
解决 Master 过程传递过去的信号
解决网络事件，比方客户端申请
这种过程模型看似跟 PHP-FPM 的解决形式相似，它们之间的区别在哪里呢？
答复这个问题，就要从两者的定位动手了。Nginx 是一个 HTTP 服务器，负责转发申请，不负责解决具体的业务。PHP-FPM 须要解决具体的业务，特地是有些是耗时的业务场景。在 Nginx+PHP-FPM 的架构中，Nginx 的 Worker 过程将申请转发给 PHP-FPM 后，并没有停下来期待 PHP-FPM 返回数据，而是设置了一个回调事件，而后就去解决请他申请了。当 PHP-FPM 业务逻辑解决完后，会执行 Nginx 中 Worker 过程设置的回调事件，这时 Nginx 的 Worker 过程就会停下手中的工作，开始解决回调函数的返回值，直到数据返回给用户端。
所以，Nginx 的 Worker 过程无需期待，能够始终解决申请。然而 PHP-FPM 的 Worker 过程须要将每个申请解决完能力解决下一个申请。
2、Nginx 实现高并发的原理剖析
Nginx 和 Apache 都是 Web 服务器，然而两者有着很大的区别。
Apache 解决申请是同步阻塞形式，每一个申请达到，apache 都会去 fork 一个子过程去解决这个申请，直到这个申请处理完毕。低并发时，这种模式没有什么毛病。面对高并发时，如果要想进步解决能力，就须要创立很多过程，过程太多了会呈现过程切换，节约 CPU 资源。
与 Apache 相比，Nginx 在解决高并发时特地有劣势。Nginx 是如何实现高并发的呢？答案就是 I/O 复用技术（select、poll、epoll 模型），即多个 I/O 能够复用一个过程。
elect、poll 原理：当连贯有 I/O 流事件产生的时候，就会去唤醒过程去解决，然而过程不晓得是哪个连贯产生的 I/O 流事件，于是就得挨个去遍历过程，遍历过程会节约大量 CPU 工夫片。select、poll 原理是一样的，只不过 select 只能察看 1024 个连贯，poll 能够察看有限个连贯。
epoll 原理连贯有 I/O 流事件产生的时候，epoll 就会去通知过程哪个连贯有 I/O 流事件产生，而后过程就去解决这个链接。
Nginx 就是采纳 epoll 模型来实现的。流程就像上文所说的一样，每解决完一个申请，就会设置一个事件回调，而后开始解决新的申请。当回调事件被触发时再腾出手来解决回调事件之后的逻辑，整个过程中不会呈现期待的状况。所以实践上 Ngnix 的一个过程就能够解决有限数量的连贯，而且无需轮询。
以上就是对文中开始提到的两个问题的解答，有点绕，可能没有齐全解释分明。前面将会在新的文章中把大家提出的问题逐渐解答分明。
残缺附件：http://github.crmeb.net/u/defu
