Nginx2:工作机制

　　我们知道进程和线程会消耗内存和其它系统资源，同时他们需要进行上下文切换。大多数现代服务器可以同时处理成千上百的进程或线程，但是当内存耗尽时，性能将下降，同时，在高IO负载时，将会出现频繁的上下文切换。
　　处理网络的常规方法是为每个连接创建一个进程或者线程，这种方式容易实现，但是扩展困难。

　　那么Nginx是怎么做的呢？How Does NGINX Work?

　　nginx 在启动后，会有一个 master 进程和多个 worker 进程。 master 进程主要用来管理 worker进程，包含：接收来自外界的信号，向各 worker 进程发送信号，监控 worker 进程的运行状态，当 worker进程退出后 (异常情况下)，会自动重新启动新的 worker 进程。而基本的网络事件，则是放在 worker 进程中来处理了。多个 worker 进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker 进程中处理，一个 worker 进程，不可能处理其它进程的请求。 worker 进程的个数是可以设置的，一般我们会设置与机器 cpu 核数一致，这里面的原因与 nginx 的进程模型以及事件处理模型是分不开的。 nginx 的进程模型，可以由下图来表示：

Google’s NSynth

Google NSynth -用器学习生成的由机声音制作音乐

下载

　　可以看到，worker 进程是由master 来管理的。master 进程会接收来自外界发来的信号，再根据信号做不同的事情。所以我们要控制 nginx，只需要向 master 进程发送信号就行了。比如， ./nginx -s reload，就是来重启 nginx， 该命令会向 master 进程发送信号，首先 master 进程在接到信号后，会先重新加载配置文件，然后再启动新的进程，并向所有老的进程发送信号，告诉他们可以光荣退休了。新的进程在启动后，就开始接收新的请求，而老的进程在收到来自 master 的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出。
　　那么，worker 进程又是如何处理请求的呢？
　　我们前面有提到，worker 进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供 80 端口的 http 服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？首先，每个 worker 进程都是从 master 进程 fork 过来，在 master 进程里面，先建立好需要 listen 的 socket 之后，然后再 fork 出多个 worker 进程，这样每个 worker 进程都可以去 accept 这个 socket(当然不是同一个 socket，只是每个进程的这个 socket 会监控在同一个 ip 地址与端口，这个在网络协议里面是允许的)。 nginx提供了一个 accept_mutex 这个东西，从名字上，我们可以看这是一个加在 accept 上的一把共享锁。有了这把锁之后，同一时刻，就只会有一个进程在 accpet 连接。 accept_mutex 是一个可控选项，我们可以显示地关掉，默认是打开的。当一个 worker 进程在 accept 这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由 worker 进程来处理，而且只在一个 worker 进程中处理。
　　那么，nginx 采用这种进程模型有什么好处呢？
　　1）每个 worker 进程独立，不需要加锁，省掉了锁开销，编程简单。
　　2）进程相互独立不影响，一个进程退出（比如出现异常）后，其它进程照常工作，服务不会中断。
　　３)没有上下文切换，减少无谓的系统开销

　　Nginx采用事件驱动处理机制，在linux里面就是epoll这样的系统调用。可以同时监控多个事件，可以设置超时时间，在超时时间之内，如果有事件准备好了，就返回准备好的事件。这样，只要有事件准备好了，我们就去处理它，只有当所有事件都没准备好时，才在 epoll 阻塞等待。这样，我们就可以进行高并发处理，我们在请求间进行不断地切换，切换是因为事件未准备好，而主动让出的。这里的切换是没有任何代价，可以简单理解为循环处理多个准备好的事件。
　　与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。更多的并发数，只是会占用更多的内存而已，这也是 nginx 性能高效的主要原因。

　　以下摘自Nginx官网：
　　When an NGINX server is active, only the worker processes are busy. Each worker process handles multiple connections in a non-blocking fashion, reducing the number of context switches.
　　Each worker process is single-threaded and runs independently, grabbing new connections and processing them. The processes can communicate using shared memory for shared cache data, session persistence data, and other shared resources.

　　Each NGINX worker process is initialized with the NGINX configuration and is provided with a set of listen sockets by the master process.
　　The NGINX worker processes begin by waiting for events on the listen sockets (accept_mutex and kernel socket sharding). Events are initiated by new incoming connections. These connections are assigned to a state machine – the HTTP state machine is the most commonly used, but NGINX also implements state machines for stream (raw TCP) traffic and for a number of mail protocols (SMTP, IMAP, and POP3).