[linux][nginx]nginx的graceful shutdown和worker shutdown timeout

前言： 某大佬问作者，nginx做proxy的时候，重新加载配置的时候，会不会影响已有的连接？ 作者基于too young too simple的认知：client和proxy之间有established连接，proxy和upstream直接有established连接；重启proxy就以为着重新启动proxy worker进程，kernel在进程exit的试试，会关闭掉所有的fd（socket本身就是fd的一种），就会发生重新连接。。。 然而，作者还是用最新的nginx做了一下实验，nginx实力打脸！作者查了一下git log，大约有两个feature起的影响比较大：graceful shutdown和worker shutdown timeout 分析： 1，client – proxy – upstream环境

简单的client – proxy – upstream环境，为了简化模型，proxy和upstream都是单worker的。实际情况下，一般worker都是per-cpu的，upstream也会比较多。 2，reload

修改nginx的conf文件，执行nginx -s reload，就会让proxy重新加载配置。在没有graceful shutdown这个feature之前，nginx proxy的worker重新启动，会给client和upstream发送FIN信号（TCP断开连接的过程）。如果client需要继续访问，就需要重新连接。 3，graceful shutdown & worker shutdown timeout

在有了graceful shutdown这个feature之后，worker并不是直接关掉的。而是让之前的连接继续保持在原来的worker上，并设置了worker的名字是“worker process is shutting down”（ps -ef | grep “worker process is shutting down”即可查到），而新的连接则连接到了新的worker上。实现细节如下图： 在nginx/src/os/unix/ngx_process_cycle.c中的ngx_worker_process_cycle函数中

对于之前的worker进程，并不是直接执行ngx_worker_process_exit退出的。会先执行ngx_close_listening_sockets把listen fd关闭掉，则可以保证不处理新的SYN包，也就不会建立新的连接了；而设置ngx_set_shutdown_timer，则可以在timeout的时候，依次主动关闭掉所有的连接，并退出。

timeout的默认时间是无限，也就是需要等到所有连接失效的时候主动关闭，这个feature需要的nginx版本是1.11.11之后：

4，影响 graceful shutdown看起来是一个非常完美的方案，是不是没有side effect呢？ 这个实验需要的量级比较大，作者没有实验，但是猜测：在执行graceful shutdown这段时间里，之前的worker上的连接是逐渐减少的，新worker的连接是逐渐增多的。在这段时间里，会短暂的存在多一倍的worker数量。而一般nginx的配置是per-cpu的，那么就2倍数量的worker短暂存在，这段时间的context switch会增多，多个进程切换也会让延迟增加一点点延迟。