周末吃饭，我的老同事问我nginx的平滑升级会么？我顿时想起来了之前面试过的一道题，考的就是这个问题。我之前的确也是操作过nginx的升级，但是因为测试环境的访问量不大，只是简单的把nginx二进制文件覆盖，并进行了nginx的重启，也就实现了升级。但是线上的nginx有那么多用户访问，需要在不影响访问的情况下，进行平滑升级。回到家登录了nginx的官网查了一下，人家写的清清楚楚，那就记录下来吧！
获取nginx的configure选项，有助于进行编译。
sbin/nginx -V备份旧的nginx二进制文件，复制新的nginx二进制文件。
mv sbin/nginx nginx.old
cp nginx sbin/nginx测试新的nginx二进制文件是否正常。
sbin/nginx -t -c nginx.conf平滑升级nginx的操作
kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`
master process 会重命名.pid为 .oldbin，执行新的nginx二进制文件，启动新的master process和新的worker process。
这时，2个nginx实例一起运行，共同处理访问请求，为了让旧的nginx逐步退出，可以使用WINCH信号。
kill –WINCH `cat /usr/local/nginx/logs/nginx.pid.oldbin`
经过一段等待时间，旧的worker process 全部关闭，新的worker process 处理所有的访问请求。这时，依然可以回滚到旧版本的nginx
Send HUP signal to the old master process - it will start the worker processes without reloading a configuration file
Send QUIT signal to the new master process to gracefully shut down its worker processes
Send TERM signal to the new master process to force it quit
If for some reason new worker processes do not quit, send KILL signal to them
After new master process quits, the old master process removes .oldbin suffix from its .pid file, and everything is exactly as before the upgrade attempt.
上面是官方给出的操作步骤，我翻译如下，
发送HUP 信号给旧的master process；
发送QUIT 信号给新的master process，从容关闭它的worker processes；
发送TERM 信号给新的master process, 强迫关闭；
如果一些原因新的worker process没有关闭，发送KILL 信号给它；
新的master process 关闭后，旧的master process 删除.oldbin后缀，这样就恢复到升级前的状态了。
6.如果升级完毕，想保留新的nginx二进制文件，发送QUIT信号给旧的master process,留下新的运行，结束！
kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin`
