nginx是以多进程的方式来工作的。当然nginx也是支持多线程的方式的,仅仅是我们主流的方式还是多进程的方式，也是nginx的默认方式。nginx採用多进程的方式有诸多优点。 
(1)nginx在启动后，会有一个master进程和多个worker进程。master进程主要用来管理worker进程，包括：接收来自外界的信号，向各worker进程发送信号，监控 worker进程的执行状态,当worker进程退出后(异常情况下)，会自己主动又一次启动新的worker进程。而主要的网络事件。则是放在worker进程中来处理了 。多个worker进程之间是对等的，他们同等竞争来自client的请求。各进程互相之间是独立的 。一个请求，仅仅可能在一个worker进程中处理，一个worker进程，不可能处理其他进程的请求。

worker进程的个数是能够设置的，一般我们会设置与机器cpu核数一致，这里面的原因与nginx的进程模型以及事件处理模型是分不开的 。

(2)Master接收到信号以后如何进行处理（./nginx -s reload ）?

首先master进程在接到信号后，会先又一次载入配置文件。然后再启动新的进程。并向全部老的进程发送信号，告诉他们能够光荣退休了。

新的进程在启动后，就開始接收新的请求，而老的进程在收到来自master的信号后，就不再接收新的请求，并且在当前进程中的全部未处理完的请求处理完毕后，再退出 .
(3)worker进程又是如何处理请求的呢？我们前面有提到。worker进程之间是平等的。每一个进程，处理请求的机会也是一样的。当我们提供80port的http服务时。一个连接请求过来，每一个进程都有可能处理这个连接，怎么做到的呢？首先，每一个worker进程都是从master进程fork过来，在master进程里面。先建立好须要listen的socket之后。然后再fork出多个worker进程，这样每一个worker进程都能够去accept这个socket(当然不是同一个socket，仅仅是每一个进程的这个socket会监控在同一个ip地址与port，这个在网络协议里面是同意的)。一般来说。当一个连接进来后。全部在accept在这个socket上面的进程。都会收到通知。而仅仅有一个进程能够accept这个连接，其他的则accept失败，这是所谓的惊群现象。

当然，nginx也不会视而不见，所以nginx提供了一个accept_mutex这个东西，从名字上。我们能够看这是一个加在accept上的一把共享锁。有了这把锁之后，同一时刻，就仅仅会有一个进程在accpet连接，这样就不会有惊群问题了。accept_mutex是一个可控选项，我们能够显示地关掉。默认是打开的。当一个worker进程在accept这个连接之后，就開始读取请求。解析请求。处理请求，产生数据后，再返回给client，最后才断开连接，这样一个完整的请求就是这种了。我们能够看到，一个请求。全然由worker进程来处理。并且仅仅在一个worker进程中处理。 
(4)nginx採用这种进程模型有什么优点呢？採用独立的进程，能够让互相之间不会影响，一个进程退出后，其他进程还在工作，服务不会中断，master进程则非常快又一次启动新的worker进程。当然，worker进程的异常退出。肯定是程序有bug了，异常退出。会导致当前worker上的全部请求失败，只是不会影响到全部请求，所以减少了风险。当然，优点还有非常多，大家能够慢慢体会。 
(5)有人可能要问了。nginx採用多worker的方式来处理请求，每一个worker里面仅仅有一个主线程，那能够处理的并发数非常有限啊。多少个worker就能处理多少个并发。何来高并发呢？非也，这就是nginx的高明之处，nginx採用了异步非堵塞的方式来处理请求。也就是说，nginx是能够同一时候处理成千上万个请求的 .对于IISserver每一个请求会独占一个工作线程。当并发数上到几千时，就同一时候有几千的线程在处理请求了。

这对操作系统来说。是个不小的挑战，线程带来的内存占用非常大。线程的上下文切换带来的cpu开销非常大。自然性能就上不去了。而这些开销全然是没有意义的。

我们之前说过，推荐设置worker的个数为cpu的核数，在这里就非常easy理解了，很多其他的worker数，仅仅会导致进程来竞争cpu资源了，从而带来不必要的上下文切换。

并且，nginx为了更好的利用多核特性，提供了cpu亲缘性的绑定选项。我们能够将某一个进程绑定在某一个核上。这样就不会由于进程的切换带来cache的失效。