Nginx的学习笔记-Nginx的进程结构

Nginx的进程结构

Nginx有两种进程结构，分别是单进程结构和多进程结构，其中多进程结构是默认的进程结构

为什么是多进程而不是多线程？

1. Nginx需要保持高可用，高可靠，如果多线程，因为线程之间是共享同一个地址空间的，当某一个第三方模块引发了一个地址空间段错误时，在地址越界出现时，会导致整个Nginx进程全部挂掉。当我们采用多进程这样的模型时，往往就没有这样的问题。
2. 分为多进程模型后，区分了MASTER进程和WORKER进程，其中MASTER进程是用来管理WORKER进程的，比如监控WORKER进程是否在正常工作，需不需要重新载入新的配置文件，需不需要热部署等等。为了保证高可靠性，第三方模块通常不会在MASTER中加入自己的代码，

Nginx的进程类型

• MASTER进程
• WORKER进程（一个或者多个）
• Cache Manager进程 （一个）
• Cache Loader进程（一个）

多个WORKER进程和CacheManager进程、CacheLoader进程都是由MASTER进程创建的子进程，并且它们共享同一片内存

为什么WORKER进程要有多个？

是因为Nginx采用事件驱动模型之后，希望每一个WORKER进程从头到尾占用一个CPU，所以我们往往不只要把WORKER进程的数量配置与服务器CPU核心数一致，还需要把每一个WORKER进程和CPU核绑定在一起，这样可以更好地使用每颗CPU上面的CPU缓存来减少缓存失效的命中率。因为绑定了CPU，相当于缓存都存在自己的CPU上，如果不绑定CPU，进程随机选择CPU，就会大概率访问到没有保存自己缓存的CPU，出现缓存失效

Nginx进程结构实例演示

我们查看当前的Nginx进程，发现25862这个master进程下有

• WORKER 6810
• CACHE MANAGER 6811

[root@iZwz909hymnzdmjfuoflygZ nginxProxy]# ps -ef | grep nginx
nobody    6810 25862  0 7月12 ?       00:00:00 nginx: worker process
nobody    6811 25862  0 7月12 ?       00:00:00 nginx: cache manager process
root     10436 10388  0 18:22 pts/0    00:00:00 grep --color=auto nginx
root     25862     1  0 7月11 ?       00:00:00 nginx: master process ./nginx

然后我们执行nginx -s reload，再查看nginx进程，master依旧是25862，但是子进程不一样了

• WORKER 10438
• CACHE MANAGER 10439

[root@iZwz909hymnzdmjfuoflygZ nginxProxy]# ./sbin/nginx -s reload
[root@iZwz909hymnzdmjfuoflygZ nginxProxy]# ps -ef | grep nginx
nobody   10438 25862  0 18:23 ?        00:00:00 nginx: worker process
nobody   10439 25862  0 18:23 ?        00:00:00 nginx: cache manager process
root     10441 10388  0 18:23 pts/0    00:00:00 grep --color=auto nginx
root     25862     1  0 7月11 ?       00:00:00 nginx: master process ./nginx

这里可以发现，即使没有修改nginx.conf中任意一个文件，reload也会创建新的子进程。另外，我们也可以通过发送信号的方式来完成对Nginx的reload，命令是

kill -SIGHUB master的Pid  # SIGHUB等同于reload

除了SIGHUB，Nginx中也有很多其他的信号，比如SIGTERM

Kill -SIGTERM worker的Pid

SIGTERM是杀死一个Worker进程，Worker被杀前会发送CHILD信号给Master，因此在Worker被杀死后Master进程会重启一个Worker进程

Nginx进程间的通信方式

Nginx是一个多进程模型，多进程之间可以使用共享内存，信号等方式进行通信。当我们做进程间的管理时，通常只使用信号。

下面是Nginx进程的信号列表

Master进程	WORKER进程	Nginx命令行
TERM,INT	TERM,INT	reload ：HUP
QUIT	QUIT	reopen ：USR1
HUP	USR1	stop : TERM
USR1	WINCH	quit : QUIT
USR2
WINCH

• TERM,INT：立刻停止
• QUIT：优雅停止，保证不会对用户发送立刻停止连接，比如TCP的RESET复位请求报文
• HUB： 重载配置文件
• USR1：重新打开日志文件，就是做日志文件的切割
• USR2 热部署使用
• WINCH 热部署使用

这些信号中，TERM、INT、QUIT 、HUB、USR1是可以通过Nginx的命令行加上特定的命令发送的，USR2、WINCH只能通过KILL的Linux的命令行直接向MASTER进程发送。

Worker进程是否也可以接受信号

WORKER进程也可以接受信号，但是通常不会直接对WORKER进程发送信号，交由MASTER进程来管理WORKER进程。

为什么nginx命令可以等同于部分信号的功能

启动Nginx以后，Ngixn会将Master的PID记录到Nginx安装目录下的logs文件夹下的Nginx.pid文件，执行【Nginx -s 命令】的时候，Nginx会去读取PID文件，从而向PID对应的Master进程发送命令对应的信号，比如收到reload发送了HUP。

本文地址：https://blog.csdn.net/weixin_38315213/article/details/107368468