在正式提供服务的产品环境下， 部署 Nginx 时都是使用一个 master 进程来管理多个worker进程，一般情况下， worker 进程的数量与服务器上的 CPU 核心数相等。 每一个worker 进程都是繁忙的， 它们在真正地提供互联网服务， master 进程则很“清闲” ， 只负责监控管理 worker 进程。 worker 进程之间通过共享内存、 原子操作等一些进程间通信机制来实现负载均衡等功能。
部署后 Nginx 进程间的关系如下图：
Nginx 是支持单进程（ master 进程） 提供服务的， 那么为什么产品环境下要按照 masterworker 方式配置同时启动多个进程呢？ 这样做的好处主要有以下两点：
❑ 由于 master 进程不会对用户请求提供服务， 只用于管理真正提供服务的 worker 进程，所以 master 进程可以是唯一的， 它仅专注于自己的纯管理工作， 为管理员提供命令行服务， 包括诸如启动服务、 停止服务、 重载配置文件、 平滑升级程序等。 master 进程需要拥有较大的权限， 例如， 通常会利用 root 用户启动 master 进程。 worker 进程的权限要小于或等于 master 进程， 这样 master 进程才可以完全地管理 worker 进程。
当任意一个 worker 进程出现错误从而导致 coredump 时， master 进程会立刻启动新的worker 进程继续服务。
❑ 多个 worker 进程处理互联网请求不但可以提高服务的健壮性（ 一个 worker 进程出错后， 其他 worker 进程仍然可以正常提供服务）， 最重要的是， 这样可以充分利用现在常见的 SMP 多核架构， 从而实现微观上真正的多核并发处理。 因此， 用一个进程（ master 进程） 来处理互联网请求肯定是不合适的。 另外， 为什么要把 worker 进程数量设置得与 CPU 核心数量一致呢？ 这正是 Nginx 与 Apache 服务器的不同之处。 在Apache 上每个进程在一个时刻只处理一个请求， 因此， 如果希望 Web 服务器拥有并发处理的请求数更多， 就要把 Apache 的进程或线程数设置得更多， 通常会达到一台服务器拥有几百个工作进程， 这样大量的进程间切换将带来无谓的系统资源消耗。 而Nginx 则不然， 一个 worker 进程可以同时处理的请求数只受限于内存大小， 而且在架构设计上， 不同的 worker 进程之间处理并发请求时几乎没有同步锁的限制， worker进程通常不会进入睡眠状态， 因此， 当 Nginx 上的进程数与 CPU 核心数相等时（ 最好每一个 worker 进程都绑定特定的 CPU 核心）， 进程间切换的代价是最小的。
举例来说， 如果产品中的服务器 CPU 核心数为 8， 那么就需要配置 8 个 worker 进程，如下图：
如果对路径部分都使用默认配置， 那么 Nginx 运行目录为 /usr/local/nginx， 其目录结构
如下。