(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的失效。