Nginx进程模型

多进程模式

在开始介绍Nginx的进程模型之前先说明下：Nginx也支持Single Master单进程模式，但是这个模式效率较低，一般只用在开发环境。所以不是本文介绍的重点。

Nginx默认采用多进程工作方式，Nginx启动后，会运行一个master进程和多个worker进程。其中master充当整个进程组与用户的交互接口，同时对进程进行监护，管理worker进程来实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。worker用来处理基本的网络事件，worker之间是平等的，他们共同竞争来处理来自客户端的请求。

既然有多个worker进程，那么请求到来时，如何分配均分worker进程来处理他们？

worker进程处理请求的过程

worker进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？

每个worker进程都是从master进程fork出来的，在master进程里面，首先会建立好监听的socket，然后再fork出多个worker进程。这样每个worker进程都可以去accept这个socket(当然不是同一个socket，只是每个进程的这个socket会监控在同一个ip地址与端口，这个在网络协议里面是允许的)。

一般来说，当一个连接进来后，所有accept在这个socket上面的进程，都会收到通知，但是只有一个进程可以accept这个连接，其它的则accept失败，这是所谓的惊群现象。

nginx提供了一个accept_mutex这个东西，从名字上，我们可以看这是一个加在accept上的一把共享锁。有了这把锁之后，同一时刻，就只会有一个进程在accpet连接，这样就不会有惊群问题了。accept_mutex是一个可控选项，我们可以显示地关掉，默认是打开的。当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。

异步非阻塞模型

当一个worker进程“竞争”到请求时，就开始处理这个请求，处理请求的方式是异步非阻塞方式，所以Nginx能处理高并发的请求。

关于异步非阻塞模型可以参考这篇文章。

参考

• https://blog.51cto.com/11859650/1918565