nginx 平滑重载 worker 进程的核心机制是 master-worker 架构配合信号量控制。具体做法是主进程（master）接收 sighup 信号后，先启动新的 worker 进程加载最新配置，待新进程就绪后，再向旧 worker 发送 sigterm 信号使其优雅退出。在此过程中，nginx 通过共享内存中的连接表实现新旧进程的通信，确保正在处理的请求不被中断，从而实现零停机更新。
Master 进程如何协调新旧 Worker 的启动顺序
Master 进程在收到重载信号后，会按照严格的时序管理进程生命周期。它首先 fork 出新的 Worker 进程，这些新进程会尝试绑定端口并初始化配置。只有当新进程成功启动并准备好接受连接时，Master 才会触发旧进程的关闭流程。这种顺序确保了服务连续性，避免了因配置错误或端口冲突导致的服务中断。
master_process on; worker_processes auto;
上述配置片段展示了 Nginx 基础配置中关于多进程模式的关键设置。master_process on 启用了 Master-Worker 架构，这是实现平滑重载的前提。如果设置为 off，则所有工作都在单个进程中完成，无法进行独立的新旧交替。在实际操作中，管理员通常通过执行 nginx -s reload 命令来触发这一系列动作，该命令向 Master 进程发送 SIGHUP 信号。
新旧 Worker 之间如何共享连接状态
在重载期间，Nginx 利用 Unix Domain Socket 或共享内存段来传递已建立的客户端连接描述符。旧 Worker 进程在处理完当前请求后，会将尚未处理完毕的连接“移交”给新 Worker，或者由新 Worker 接管监听套接字。这种机制依赖于操作系统层面的文件描述符继承和共享技术，使得客户端感知不到服务的重启过程。
// 伪代码示意连接传递逻辑
if (new_worker_ready) {
send_signal(OLD_WORKER, SIGTERM);
} else {
wait_for_new_worker();
}
这段伪代码描述了 Master 进程内部的状态机逻辑。关键在于 new_worker_ready 的判断，这通常通过检查新进程是否成功绑定了监听端口来确定。一旦确认新进程就绪，Master 便发送 SIGTERM 给旧进程。旧进程收到信号后，会停止接受新的连接请求，但会继续处理已有的连接，直到所有连接关闭或达到超时时间，然后才彻底退出。这种设计保证了在高并发场景下，用户的请求不会丢失。
基于 worker_shutdown_timeout 参数的具体行为影响
当配置了 worker_shutdown_timeout 参数时，旧 Worker 进程在收到 SIGTERM 后，如果在指定时间内未能处理完所有活跃连接，将被强制终止。这个参数直接影响了平滑重载的最终效果和潜在的数据丢失风险。默认情况下，如果没有设置该超时值，旧进程可能会无限期等待，导致资源占用。
假设我们设置了 worker_shutdown_timeout 10s。在重载发生时，旧 Worker 开始倒计时。如果 10 秒内还有未完成的长连接（如 WebSocket 或大文件下载），Nginx 会主动断开这些连接。对于开发者而言，这意味着需要评估业务中是否存在长时间持有的连接，并据此调整超时策略。若未正确配置，可能导致部分用户请求失败；若配置过长，则可能拖慢重载速度，延长系统处于不稳定状态的时间。因此，合理设置该参数是平衡服务可用性和更新效率的关键。
