探究Nginx中reload流程的原理真相
今天这篇文章主要来介绍下Nginx的reload流程。实际上在之前文章中，在更改了nginx配置文件时，我们都会执行nginx-sreload命令，我们执行这条命令的原因是希望nginx不停止服务始终在处理新的请求的同时把nginx的配置文件平滑的把旧的nginx.conf配置更新为新的nginx.conf配置。
这样一个功能对于nginx非常有必要，但是有时候我们会发现在执行nginx-sreload命令后，worker子进程的数量会变多了，这是因为老的配置运行的worker进程长时间没有退出，当使用stream做四层反向代理的时候，可能这种场景会更多。
那么下面我们通过分析nginx的reload流程，来探究下nginx到底做了些什么？所谓优雅的退出和立即退出有什么区别？
reload流程
第一步在修改好nginx的配置文件nginx.conf后，向master进程发送HUP信号，这实际上和我们在命令行执行nginx-sreload命令效果是一样的。
那么master进程在收到HUP信号以后，会在第二步检查我们的配置文件语法是否正确，也就是说我们并不一定非要在nginx-sreload前执行nginx-t检验下语法是否正确，因为在第二步nginx的master进程一定会执行这个步骤。
在nginx的配置语法全部正确以后，master进程会打开新的监听端口，为什么要在master进程中打开新的监听端口？因为我们可能在nginx.conf中会引入新的例如443或者之前我们没有打开的的监听端口，而所有worker进程是master进程的子进程，子进程会继承父进程所有已经打开的端口，这是linux操作系统定义的，所以第三步，我们master进程打开了可能引入的新的监听端口。
接下来mster进程会用新的nginx.conf配置文件来启动新的worker子进程，那么老的worker子进程会怎么样呢？
我们会在第五步在启动新的worker子进程以后，由master进程再向老worker子进程发送QUIT信号，QUIT信号和TERM，INT信号是不一样的，QUIT信号是请优雅地关闭子进程，这时候需要关注顺序，因为nginx需要保证平滑，所以要先启动新的worker子进程，再向老的worker子进程发送QUIT信号。
那么老的master子进程收到QUIT信号后，首先关闭监听句柄，也就是说这个时候新的连接只会到新的worker子进程，所以虽然他们之间有时间差，但是时间是非常快速的，那么关闭监听句柄后，处理完当前连接后就结束进程。
下面看reload不停机载入新配置的图示。
reload不停机载入新配置
master进程上原先有四个绿色的worker子进程，它们使用了老的配置，当我们更改了nginx.conf配置文件后，向master发送SIGHUP信号或者执行reload命令，然后master会用新的配置文件启动四个新的黄色worker子进程，此时是四个老的绿色worker子进程和四个新的黄色的worker子进程是并存的。那么老的worker子进程在正常的情况下会在处理已经建立好的连接上的请求之后关闭这个连接，哪怕这个连接是keeplive请求也会正常关闭。
但是异常情况，如果有一些请求出现问题，客户端长时间无法处理，那么就会导致这个请求长时间停留在这个worker子进程当中，那么这个worker子进程会长时间存在，因为新的连接已经跑在黄色的worker子进程中，所以影响并不会很大，唯一会影响的就是绿色的worker子进程会长时间存在，但也只影响已存在的连接，不会影响新的连接。
我们有什么办法处理呢？在新版本中提供了一个新的配置worker_shutdown_timeout，也就是说最长等待多长时间，这样master进程启动新的黄色worker进程之后，如果老的worker进程一直没有退出，时间到了之后会强制把老的worker进程退出掉。
总结
本文主要讲解了Nginx平滑升级新的配置文件的流程，在我们了解了优雅关闭worker子进程和启动新配置的worker子进程流程间的关系后，我们可以更好地处理罕见的异常场景。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持毛票票。
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。