Nginx 中 Master Process 怎样协调进程重启任务

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：确认响应头、重写规则、限速策略等新配置已实际生效