上一篇我们介绍了Nginx的是适用场景。今天我们来介绍一下Nginx的进程结构模型。
nginx 分为两种进程结构：单进程 / 多进程。
单进程模型下主进程就是工作进程，此时没有监控进程，主要是用于调试用。
我们生产环境主要是使用多进程模型。所以我们主要介绍多进程模型。
多进程模型下Nginx启动后会有多个进程。
首先会有1个主进程master_process（也叫监控进程）主要做进程管理的，监控worker进程是否需要做热部署，重载配置文件等。如果某工作进程意外退出，监控进程将重新fork()生成一个新的工作进程。
主进程还会fork()一些子进程。子进程分为两类：一类是work进程，另一类是cache相关进程。
work进程一般设置成cpu核心数 ，Nginx采用了事件驱动，目的是为了让每个work进程可以独占一个cpu，更好地使用cpu缓存，减少缓存失效的命中率，以提高处理效率。work进程间的通信是通过共享内存解决的。
在Ngnix中，work进程会去accept请求，这与php扩展swoole不同，swoole在master进程内有自己的reactor线程组用来accept请求，所以swoole的服务可以自主的分发请求到不同的worker进程上。
cache类进程 有cache manager / cache loader。
这些进程之间会相互进行通信，以传递一些信息（主要是监控进程往工作进程传递）。除了自身进程之间的相互通信，Nginx还凭借强悍的功能模块与外界四通八达，比如通过upstream与后端Web服务器通信、依靠fastcgi与后端应用服务器通信等。
那么有没有想过Nginx为什么采用多进程结构，而不是多线程结构呢？
Nginx要保持它自身的高可靠性，如果使用多线程模型，多线程之间是共享同一个地址空间的。
如果有一个第三方模块引发了地址空间导致的段错误时，会导致整个Nginx进程就挂了。
当我们采用多进程模型时，就会很好地规避这个风险。
Nginx在设计时，允许第三方模块添加自己的功能，那么我们知道了这个潜在风险，是不是就不会往master进程里去添加第三方模块的功能了呢？
欢迎沟通讨论！
