Nginx的学习笔记-Nginx的进程结构
Nginx的进程结构
Nginx有两种进程结构,分别是单进程结构和多进程结构,其中多进程结构是默认的进程结构
为什么是多进程而不是多线程?
- Nginx需要保持高可用,高可靠,如果多线程,因为线程之间是共享同一个地址空间的,当某一个第三方模块引发了一个地址空间段错误时,在地址越界出现时,会导致整个Nginx进程全部挂掉。当我们采用多进程这样的模型时,往往就没有这样的问题。
- 分为多进程模型后,区分了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