Nginx 进程间的关系

部署Nginx 都是使用一个 master进程来 管理多个 worker进程 ，一般情况下进程的数量与服务器 上 的CPU数量 相同，每一个worker的 进程都是繁忙的 。她们真正提供互联网服务，master进程只是 负责监控管理 worker进程，worker进程之间通过 共享内存 、原子操作等 一些进程 间的通信机制来实现负载均衡机制。

为什么产品环境是按照master-worker方式进行的？

• 由于master 进程是不会对用户提供请求服务，只用于管理真正提供服务的worker进程， master进程是唯一的，它仅专注于自己的纯管理工作，为管理员提供命令行服务，包括启动服务，停止服务，重新配置文件，平滑升级等。master进程的权限等级一般要大于或等于worker进程
• 多个worker进程处理互联网请求不但可以提高服务的健壮性 （一个worker进程出错后，其他的进程仍然可以正常提供服务），最重要的是，这样可以利用现在常见的SMP多核架构，从而 实现微观上真正多核并发处理。
• 为什么 要把worker进程数量设置得与CPU核心数量一致呢？这正是Nginx与Apache服务器的不同之处。
  在Apache上的 每个 进程在一个时刻只处理一个请求，因此，如果希望Web服务器拥有并发处理请求更多，就要 把Apache的进程或进程 数量设置更多，通常一台服务器拥有几百个工作进程 ，这样的大量的进程间的切换带来所谓的 系统资源的消耗。Nginx则 不是这样，一个 Worker进程可以同时处理请求 数只受限内存的大小 ，架构上，不同的worker进程之间处理并发 请求时几乎 没有同步锁的限制。worker通常 不会进入睡眠状态，当Nginx的进程数与CPU数量相等 时，理论上，进程间的切换的代价最小的。

小结

有人可能要问了，nginx采用多worker的方式来处理请求，每个worker里面只有一个主线程，那能够处理的并发数很有限啊，多少个worker就能处理多少个并发，何来高并发呢？非也，这就是nginx的高明之处，nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的。想想apache的常用工作方式（apache也有异步非阻塞版本，但因其与自带某些模块冲突，所以不常用），每个请求会独占一个工作线程，当并发数上到几千时，就同时有几千的线程在处理请求了。这对操作系统来说，是个不小的挑战，线程带来的内存占用非常大，线程的上下文切换带来的cpu开销很大，自然性能就上不去了，而这些开销完全是没有意义的。

为什么nginx可以采用异步非阻塞的方式来处理呢，或者异步非阻塞到底是怎么回事呢？我们先回到原点，看看一个请求的完整过程。首先，请求过来，要建立连接，然后再接收数据，接收数据后，再发送数据。具体到系统底层，就是读写事件，而当读写事件没有准备好时，必然不可操作，如果不用非阻塞的方式来调用，那就得阻塞调用了，事件没有准备好，那就只能等了，等事件准备好了，你再继续吧。阻塞调用会进入内核等待，cpu就会让出去给别人用了，对单线程的worker来说，显然不合适，当网络事件越多时，大家都在等待呢，cpu空闲下来没人用，cpu利用率自然上不去了，更别谈高并发了。好吧，你说加进程数，这跟apache的线程模型有什么区别，注意，别增加无谓的上下文切换。所以，在nginx里面，最忌讳阻塞的系统调用了。不要阻塞，那就非阻塞喽。非阻塞就是，事件没有准备好，马上返回EAGAIN，告诉你，事件还没准备好呢，你慌什么，过会再来吧。好吧，你过一会，再来检查一下事件，直到事件准备好了为止，在这期间，你就可以先去做其它事情，然后再来看看事件好了没。虽然不阻塞了，但你得不时地过来检查一下事件的状态，你可以做更多的事情了，但带来的开销也是不小的。所以，才会有了异步非阻塞的事件处理机制，具体到系统调用就是像select/poll/epoll/kqueue这样的系统调用。它们提供了一种机制，让你可以同时监控多个事件，调用他们是阻塞的，但可以设置超时时间，在超时时间之内，如果有事件准备好了，就返回。这种机制正好解决了我们上面的两个问题，拿epoll为例(在后面的例子中，我们多以epoll为例子，以代表这一类函数)，当事件没准备好时，放到epoll里面，事件准备好了，我们就去读写，当读写返回EAGAIN时，我们将它再次加入到epoll里面。这样，只要有事件准备好了，我们就去处理它，只有当所有事件都没准备好时，才在epoll里面等着。这样，我们就可以并发处理大量的并发了，当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请求当然只有一个了，只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里的切换是没有任何代价，你可以理解为循环处理多个准备好的事件，事实上就是这样的。与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。更多的并发数，只是会占用更多的内存而已。 我之前有对连接数进行过测试，在24G内存的机器上，处理的并发请求数达到过200万。现在的网络服务器基本都采用这种方式，这也是nginx性能高效的主要原因。