探究Nginx中reload流程的原理真相

探究Nginx中reload流程的原理真相

本文详细介绍了在Nginx中研究重载步骤的基本原理。原文根据示例代码非常详细，对大家的学习培训或者工作都有一定的参考价值。有需要的朋友会陪我去学习了解一下。

今天本文的重点是详细介绍Nginx的重装步骤。其实在之前的文章中，当nginx的配置文件改变时，大家都会实现nginx-sreload指令。大家之所以执行这个指令，是期望nginx不会自始至终终止服务项目，解决新的需求。此外，nginx的配置文件将从旧的nginx.conf配置平滑升级到新的nginx.conf配置。

这个角色对于nginx来说是必要的，但是有时您会发现，在nginx-sreload指令实现之后，worker子进程的总数会增加。这是因为配置和 *** 作的旧工作进程很长时间没有被撤销。当stream作为四层反向代理时，很可能会出现大量这样的场景。

所以我们根据nginx的重装步骤分析，来研究一下nginx都做了些什么。说白了，优雅退出和立即退出有什么区别？

重新加载步骤

第一步是在更改nginx的配置文件nginx.conf后，将HUP信号推送到主进程，这其实和在cmd中实现nginx-sreload指令的实际效果是一样的。

然后，主进程在收到HUP信号后，会在第二步检查每个人简介的英语语法是否合适。换句话说，你不必在nginx-s重新加载之前实现nginx-t来检查英文语法是否合适，因为nginx的主进程在第二步肯定会实现这个过程。

nginx的配置英语语法都没问题后，主进程会打开一个新的监听端口号。为什么它要在主进程中打开一个新的监控端口号？因为您很可能会导入一个新的监控端口号，如443或您以前在nginx.conf中没有打开的端口号，并且所有工作进程都是主进程的子进程，这将继承继父进程已经打开的所有端口号。它是由linux计算机 *** 作系统定义的，因此在第三步中，您的主进程打开一个可能要导入的新监视端口号。

接下来，mster进程将使用新的nginx.conf配置文件启动新的worker子进程，那么旧的worker子进程会发生什么情况呢？

大家会在第五步启动新工人子进程，然后主进程会把退出信号推送给老工人子进程。退出信号不同于TERM和INT信号。请优雅地关掉子进程，此刻一定很在意顺序。由于nginx必须保证流畅，所以你应该先启动新的worker子进程，然后把退出信号推送给老的worker子进程。

然后，老主子进程收到退出信号后，会先关闭监控句柄。换句话说，此时，新的连接将始终指向新的worker子进程。所以这中间虽然有时间差，但是时间很快。然后，在关闭监控句柄后，在解决当前连接后，该过程将结束。

见下面reload连续L波段进入新配置的图例。

reload将L波段保持在新配置中

主流程中最初有四个emeraldworker子流程，它们应用了旧的配置。在我们更改了nginx.conf配置文件之后，我们将SIGHUP信号推送到主进程或者实现了reload指令，然后主进程使用新的配置文件启动了四个新的黄色worker子进程。此时，四个旧的祖母绿工人子进程和四个新的黄色工人子进程共存。然后旧的worker子进程可以在正常情况下解决已经创建的连接的需求后关闭该连接。即使连接是keeplive需求，一切都会正常关闭。

但是，不正常的现象，如果有些需求比较难，移动客户端长期解决不了，就会造成这个需求长期停留在这个工作者子流程中，这个工作者子流程会长期存在。因为新的连接已经运行在黄色工作者子进程中，所以危害不会很大。唯一的危害是祖母绿工作者子进程会长期存在，但只会危害已有的连接，不容易危害新的连接。

你能做什么来解决它？在最新版本中，提出了一个新的配置worker_shutdown_timeout，换句话说，就是最大等待时间。主进程启动新的黄色工作进程后，如果旧的工作进程还没有退出，时间到了就会强制退出旧的工作进程。

摘要

本文阐述了Nginx平滑升级新配置文件的步骤。在我们知道优雅地关闭工作者子进程和启动新配置的工作者子进程之间的关系之后，我们可以更好地解决罕见的异常情况。

文章里的内容就这些了。期待对大家的学习和培训有所帮助，也期待大家的应用。