一、什么是 Nginx 平滑升级

原笔记把“平滑升级”理解为：

  • 不直接粗暴停止现有 Nginx
  • 而是在现有服务继续工作的同时
  • 逐步让新版本二进制接管进程

这样做的目的就是尽量避免明显业务中断。

对于线上服务来说，这种热替换思路比“先停再换再起”更稳妥。

二、原笔记总结的平滑升级步骤

原笔记先给出了一个简洁流程表，可以概括为四步：

1、准备好已经测试通过的新 nginx 命令
2、备份当前环境里的旧命令，并用新命令替换
3、给当前运行中的 Nginx 发送 USR2 信号
4、验证新版本接管成功后，再关闭旧版本进程

这套步骤里最关键的并不是换文件，而是“通过信号让新旧版本并存一段时间，再完成切换”。

三、升级前要先确认当前运行状态

原笔记先检查了当前版本和进程情况：

nginx -v
ps -ef | grep nginx

从这里至少要先知道两件事：

  • 当前运行的版本号
  • 当前 Master 进程 PID

后面发送信号时，必须明确操作的是哪个旧版本 Master。

四、先备份旧二进制，再替换新版本

原笔记的操作是先把旧版本备份：

mv /sbin/nginx /sbin/nginx-old-1.24.0

再把新的二进制移动到原路径：

mv nginx /sbin/
nginx -V

这里的关键点是：

  • 运行中的旧进程此时还没有退出
  • 只是磁盘上的 nginx 命令已经换成新版本了

这正是后续热切换的基础。

五、kill -USR2 到底做了什么

原笔记接下来执行的是：

cat /run/nginx.pid
kill -USR2 2726

这里的 2726 是旧版本 Master 的 PID。

发送 USR2 后，Nginx 的行为可以理解为：

  • 保留旧的 Master 和 Worker
  • 同时启动一套新的 Master 和 Worker
  • 把旧 PID 文件改名为 .oldbin
  • 让新的 PID 文件指向新版本 Master

这也是为什么它被称为“平滑升级”——新旧版本会暂时同时存在。

六、如何确认新旧版本已经并存

原笔记在 kill -USR2 后，通过：

ps -ef | grep nginx
ll /run/nginx.pid*
cat /run/nginx.pid
cat /run/nginx.pid.oldbin

观察到了两类现象：

  • 进程列表里同时出现旧 Master 和新 Master
  • /run/nginx.pid 指向新版本 PID
  • /run/nginx.pid.oldbin 保留旧版本 PID

这一步非常重要，因为它证明：

  • 新版本已经成功拉起
  • 旧版本仍然还在兜底
  • 当前处于过渡阶段

七、什么时候可以下线旧版本进程

当确认：

  • 新版本配置正确
  • 新版本进程已经正常工作
  • 业务访问没有异常

就可以把旧 Master 干掉。
原笔记直接执行：

kill 2726

然后再次查看：

ll /run/nginx.pid*

此时只剩下新的 PID 文件，说明切换已经完成。

八、这套流程最适合解决什么问题

原笔记虽然案例不长，但非常适合用于理解以下场景：

  • 自己编译了一个带特殊模块的新 Nginx/Tengine
  • 想尽量减少业务中断地切换到新版本
  • 想先让新旧版本并存验证，再回收旧进程

相比直接 pkill nginx 再重启，这种方式更适合对连续性要求较高的服务环境。

九、小结

Nginx 平滑升级的本质不是“换个文件”，而是“让新旧版本在一段时间内共同存在，然后完成接管”。
原笔记中的核心动作可以浓缩成：

  • 备份旧二进制
  • 替换新二进制
  • 对旧 Master 发 USR2
  • 观察新旧 PID
  • 确认无误后结束旧进程

把这套流程理解清楚之后，后面再做带模块版本切换就会更有把握。