Master Process 是 Nginx 平滑重启的核心协调者，负责调度、信号转发与生命周期管理，通过新旧 Worker 并行过渡实现无中断重启：先校验配置，再 fork 新 Worker 并加载新配置，随后通知旧 Worker 优雅退出，最后监控并回收进程。
Master Process 是 Nginx 实现平滑重启的核心协调者，它不处理请求，只负责调度、信号转发和生命周期管理。重启不是“杀旧启新”，而是新旧 Worker 并行过渡，全程无服务中断。
配置校验与启动新 Worker
收到 SIGHUP 或执行 nginx -s reload 后，Master 首先做语法检查（等效于 nginx -t）。失败则立即终止流程，旧 Worker 继续运行；成功后，Master 调用 fork() 启动一批新 Worker 进程，加载新配置、初始化模块、绑定监听端口。
- 新 Worker 启动时能立即接受新连接，即使旧 Worker 仍在处理长连接
- Linux 内核支持
SO_REUSEPORT，或由旧 Worker 主动释放监听 socket，确保端口复用无冲突 - 若新 Worker 初始化失败（如模块加载异常），Master 不会终止旧进程，服务持续可用
通知旧 Worker 进入优雅退出状态
配置加载成功后，Master 向所有现存 Worker 发送 QUIT 信号——不是强制终止，而是触发“软退出”逻辑。
- 旧 Worker 立即停止
accept()新连接，但保持已有 TCP 连接活跃 - 继续完成正在传输的响应、上传未结束的请求、Keep-Alive 连接上的后续请求
- 可通过
worker_shutdown_timeout 10s;设置最大等待时间，超时后强制关闭剩余连接
进程状态监控与收尾
Master 持续轮询各 Worker 状态，维护内部进程表（ngx_processes），直到全部旧 Worker 自行退出。
- 旧 Worker 完成所有任务且无活跃连接后，调用
exit()正常终止 - Master 将其从进程表中移除，并回收资源
- 整个过程 PID 不变（Master 进程 ID 不变），但内部 worker 数组已更新
验证重启是否真正生效
不能只看命令是否返回成功，需结合多维度确认：
- 执行
ps aux | grep nginx：应同时看到running（新 Worker）和exiting（旧 Worker）状态 - 查看
error.log：有"reloading configuration"和旧 Worker 的"exit"日志行 - 访问业务接口或用
curl -I：确认响应头、重写规则、限速策略等新配置已实际生效
