Nginx 的进程结构，你明白吗？

Nginx 进程结构

这篇文章咱们来看下 Nginx 的进程结构，Nginx 其实有两种进程结构：

• 单进程结构
• 多进程结构

单进程结构实际上不适用于生产环境，只适合咱们作开发调试使用。由于在生产环境中咱们必须保持 Nginx 足够健壮以及 Nginx 能够利用多核的一个特性，而单进程的 Nginx 是作不到这一点的，因此默认的配置中都是打开为多进程的 Nginx。

咱们来看一下，多进程的 Nginx 结构中它的进程模型是怎样的。

多进程中的 Nginx 进程架构以下图所示，会有一个父进程（Master Process），它会有不少子进程（Child Processes），这些子进程会分为两类：

• worker 进程
• cache 相关的进程

为何 Nginx 采用多进程结构而不是多线程结构呢？

由于 Nginx 最核心的一个目的是要保持高可用性、高可靠性，而当 Nginx 若是使用的是多线程结构的时候，由于线程之间是共享同一个地址空间的，因此当某一个第三方模块引起了一个地址空间致使的段错误时、在地址越界出现时，会致使整个 Nginx 进程所有挂掉。而当采用多进程模型时，每每不会出现这样的问题。从上图能够看到 Nginx 在作进程设计时，一样遵循了实现高可用、高可靠这样的一个目的。

好比说在 master 进程中，一般第三方模块是不会在 master 部分加入本身的功能代码的。虽然 Nginx 在设计时，容许第三方模块在 master 进程中添加本身独有的、自定义的一些方法，可是一般没有第三方模块这么作。

master 进程被设计用来的目的是作 worker 进程的管理的，也就是全部的 worker 进程是处理真正的请求的，而 master 进程负责监控每一个 worker 进程是否是在正常的工做、需不须要作从新载入配置文件、需不须要作热部署。

而 cache （缓存）是在多个 worker 进程间共享的，并且缓存不只要被 worker 进程使用，还要被 cache manager 和 cache loader进程 使用。cache manager 和 cache loader 也是为反向代理时，后端发来的动态请求作缓存所使用的，cache loader 只是用来作缓存的载入、cache manager 用来作缓存的管理。实际上每一个请求处理时，使用到缓存仍是由 worker 进程来进行的。

这些进程间的通信，都是使用共享内存来解决的。能够看到cache manager 和 cache loader各有一个进程，master 进程由于是父进程，因此确定只有一个。那么 worker 进程为何会有不少呢？这是由于 Nginx 采用了事件驱动引擎之后，他但愿每个 worker 进程从头至尾占有一颗CPU，因此每每不止要把 worker 进程的数量配置与咱们服务器上的 CPU核数一致之外，还须要把每个worker进程与某一颗CPU核绑定在一块儿，这样能够更好的使用每颗CPU核上面的CPU缓存来减小缓存失效的命中率。

以上就是 Nginx 的进程结构的介绍，了解这些后更有助于咱们去配置 Nginx。

刚才咱们介绍了 Nginx 使用了多进程模型，由 master 做为父进程启动许多子进程，也知道了 Nginx 父子进程之间是经过信号来管理的，接下来经过一个实例给你们直观的看下父子进程以及信号之间是如何工做的。

Nginx 的进程结构实例

首先启动 Nginx，并在 Nginx 中启动了两个 worker 进程，经过 ps 命令能够看到当前进程 PID 和父进程 PID，有一个 nginx master 进程是由 root 用户起的，进程 PID 是 2368。还有两个 worker 进程和 cache 进程，它们是由 2368 进程起来的。它们的进程 PID 分别为 8652，8653，8655。

如今咱们使用 ./sbin/nginx -s reload 命令，会把以前的 worker 进程和 cache 进程优雅的退出，而后再使用的新的配置项启动新的 worker 进程，这里咱们并无改变配置，可是咱们能够看到老的三个子进程会退出，并生成新的子进程。

能够看到，以前的三个子进程，如今已经都不在了，反而由 2368 新起了 8657，8658，8660 三个子进程。

[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4751  4688  0 11:41 pts/0    00:00:00 grep --color=auto nginx
nginx     8652  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8653  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8655  2368  0 Nov12 ?        00:00:00 nginx: cache manager process
[root@wupx nginx]# ./sbin/nginx -s reload
[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4753  4688  0 11:43 pts/0    00:00:00 grep --color=auto nginx
nginx     8657  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8658  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8660  2368  0 Nov12 ?        00:00:00 nginx: cache manager process

执行命令以后能够看到 worker 的 PID 已经变化了（以前讲过 ./sbin/nginx -s reload 跟 kill -SIGHUP 做用是同样的。）。

kill -SIGTERM 是向现有的 worker 进程发送退出的信号，对应的 worker 进程就会退出；进程在退出时，会自动向父进程 master 发送一个退出信号，master 就知道他的子进程退出了，而后新起一个 worker 进程。

[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4753  4688  0 11:43 pts/0    00:00:00 grep --color=auto nginx
nginx     8657  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8658  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8660  2368  0 Nov12 ?        00:00:00 nginx: cache manager process
[root@wupx nginx]# kill -SIGTERM 8658
[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4753  4688  0 11:44 pts/0    00:00:00 grep --color=auto nginx
nginx     8657  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8660  2368  0 Nov12 ?        00:00:00 nginx: cache manager process
nginx     8663  2368  0 Nov12 ?        00:00:00 nginx: worker process

经过实例演示，咱们能够看到 Nginx 的进程结构以及 Nginx 使用信号的方式，其实命令行中的许多子命令就是再向 master 进程发送信号而已。