nginx平滑升级与重载依托master-worker架构，通过进程解耦、信号协作和原子操作实现无中断服务：配置重载触发sighup使master校验并fork新worker，再优雅关闭旧worker；二进制升级通过usr2启动新master+worker双组共存，再用winch/quit逐步关停旧进程；配置更新须用mv原子替换，所有操作均前置校验确保失败回退。
配置重载（nginx -s reload）靠 master 主导+worker 无感切换
修改 nginx.conf 后执行 nginx -s reload，实际触发以下流程：
- master 进程收到 SIGHUP 信号，重新读取并校验配置语法；失败则中止，旧配置继续运行
- 校验成功后，master 基于新配置 fork 出一批新 worker 进程，每个新 worker 拥有独立、只读的配置副本
- master 向旧 worker 发送 QUIT 信号，旧 worker 不再接受新连接，但会处理完正在响应的请求后自行退出
- 整个过程无共享内存或配置写入，新旧 worker 并行运行一段时间，连接自然过渡，用户无感知
二进制升级（平滑升级 nginx 版本）靠双 master 共存+渐进切换
替换 nginx 可执行文件并升级版本时，不终止服务的关键在于引入第二组进程：
- 先备份原 binary，编译好新版本后，用
cp -f替换/usr/sbin/nginx（确保权限一致） - 向当前 master 发送 USR2 信号：
kill -USR2 $(cat /var/run/nginx.pid)，旧 master 启动新 master + 新 worker，同时保留自身及旧 worker 继续服务 - 此时系统中存在两组进程：旧 master（pid 写入
nginx.pid.oldbin）和新 master（pid 仍为nginx.pid） - 确认新进程就位后，向旧 master 发送 WINCH 信号，使其逐步关停旧 worker；再发 QUIT 关闭旧 master
配置文件更新本身依赖原子性，避免读到中间态
worker 进程启动后只读取一次配置，所以配置变更必须保证“全有或全无”：
- 不要直接编辑线上
nginx.conf，应先写入临时文件（如nginx.conf.new） - 用
mv nginx.conf.new nginx.conf完成原子替换（底层是 rename 系统调用，不可中断） - reload 时 master 总是读取最新 inode 内容，worker 在下次 reload 启动时才加载新副本，不会出现半截配置
所有操作都以校验为前提，失败即回退
无论是 reload 还是升级，Nginx 都把安全边界设得很前：
-
nginx -t必须在 reload 前执行，master 也会在 reload 中隐式做一次校验，任一环节失败都不影响旧进程 - 升级过程中若新 binary 异常，可随时 kill 新 master，旧 master 仍在运行，业务不受影响
- 旧进程 pid 文件自动重命名（
.oldbin），便于脚本识别和回滚控制
