再谈reload配置文件,Nginx热部署和优雅地关闭worker进程

1.reload重载配置文件的真相

    我们希望Nginx不停止服务的同时还能完成升级,reload重载文件配置就是一种升级方式.
我们希望能够平滑地新老过渡,将旧的配置文件更新为新的配置文件并且新配置文件被使用,
但有时候我们会发现Nginx的worker进程变多了,这其实是因为老的配置所运行的worker进程长时间
没有退出,我们使用stream做四层反向代理的时候,可能这种场景会更多,面对这些情况,
我们需要知道nginx -s reload到底做了什么.


    在正常情况下是可以平滑更换配置文件的,但是也会出现异常情况,比如说一些请求出现
问题了,客户端长时间没有处理就会导致这个请求占用在老配置文件的worker进程上面,
这样这个老的worker进程就会一直存在,当然新的连接已经跑在新配置文件的worker子
线程中了,所以影响不会很大,唯一的影响就是下图中绿的旧的子进程长时间存在,但这也
只是影响已存在的连接,不会影响新的连接.
 
    这时有什么办法来处理上面说的情况呢?
新的Nginx版本中已经提供了一个配置项work_shutdown_timeout(最长会等多久),也就是master进程
在起黄色的进程的时候,会添加一个定时器work_shutdown_timeout,时间到了以后如果worker子进程
如果还没有退出,立刻强制的把老的worker子进程退出.

    我们还可能遇到更加罕见的场景,理解了reload流程(优雅地关闭旧的worker子进程和启动新的worker
子进程)之后,我们也许能更从容地面对这些棘手的问题.

再谈reload配置文件,Nginx热部署和优雅地关闭worker进程_第1张图片

 再谈reload配置文件,Nginx热部署和优雅地关闭worker进程_第2张图片

2.热升级流程

不停机更新nginx二进制文件.
新的master进程是老的master进程的子进程,但新的master进程用的是新的binary文件来载入的.

 再谈reload配置文件,Nginx热部署和优雅地关闭worker进程_第3张图片

 再谈reload配置文件,Nginx热部署和优雅地关闭worker进程_第4张图片

3.优雅地关闭worker进程

优雅地关闭是针对worker进程的,因为只有worker进程才会处理请求,
如果我们直接关闭连接,会使得用户收到错误的提示,优雅地关闭是指
Nginx进程可以识别出当前连接没有正在处理请求,这时来关闭连接.


Nginx是不是一直能做到优雅地关闭子进程呢?
并不是的,比如说代理websocket协议时,在websocket协议后面进行
通讯的fream帧中,Nginx是不解析帧的,所以此时Nginx是无法知道处
理是否已经完成了的;再比如,Nginx做tcp和udp层的反向代理的时候,
它也没法知道一个请求究竟要经过多少次报文才算真正地结束,但是对于
http请求来说,Nginx是可以做到的,所以我们说的优雅地关闭针对的一般
是http请求:



优雅地关闭的期望流程:
1.设定定时器worker_shutdown_timeout,并设置标志位,告诉Nginx要进入优雅关闭的流程了;
2.关闭监听句柄,保证所在的worker进程不会再去处理新的连接了;
3.关闭空闲连接(Nginx为了保证自己对资源的利用是最大化的,经常会保存一些空闲的不断开的连接);
4.在循环中等待全部连接关闭(这一步可能时间非常长);
5.退出进程.

第四步中处理流程可能会超过worker_shutdown_timeout,但是只要配置了这个参数,一旦时间到了,
子进程就会立刻退出,这种情况也不算优雅关闭了.

在Nginx的使用过程中,我们需要考虑Nginx有没有能力去判定一个连接此时应该被正确的关掉,如果出现了
错误,有些模块或者有一些客户端不能正常地处理请求是,Nginx需要有一些措施比如说worker_shutdown_
timeout来保证Nginx老的worker进程可以正常地退出.

 

你可能感兴趣的:(开源软件,nginx)