我要评论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
您可能感兴趣的文章:
如您对本文有疑问或者有任何想说的，请点击进行留言回复，万千网友为您解惑！
网友评论