Nginx 多进程模型如何达成配置管理与生命周期的平衡

Nginx多进程模型通过Master统一管控、Worker只读运行、信号驱动协同实现配置与服务平衡。Master解析并校验配置，Worker仅继承内存副本；reload时新旧Worker共存，各司其职，保障平滑过渡与连接不中断。

Nginx 多进程模型的配置管理与生命周期平衡，本质是靠 Master 统一管控 + Worker 只读运行 + 信号驱动协同 三者配合实现的。它不靠锁、不靠轮询，而是用进程职责分离和操作系统信号机制，让配置更新与服务运行互不干扰。

Master 是唯一配置决策中心

所有配置变更都必须经由 Master 进程触发，Worker 进程从不主动读取磁盘配置文件：

• 启动时，Master 解析 nginx.conf 并校验语法；若失败则直接退出，不会拉起任何 Worker
• Worker 启动后，只继承 Master fork 时已加载到内存的配置副本，运行期间该副本只读、不可修改
• reload 操作（如发送 SIGHUP）由 Master 接收后统一处理：先解析新配置，成功后再 fork 新 Worker，旧 Worker 继续运行原配置直到自然退出

Worker 生命周期完全由 Master 主导

每个 Worker 的诞生、运行、退出都处于 Master 的实时监控之下：

• Master 通过 SIGCHLD 信号捕获 Worker 异常退出，并立即调用 ngx_reap_children() 清理僵尸进程、fork 新进程补位
• QUIT 或 TERM 信号下发时，Master 通知所有 Worker 优雅关闭：不再 accept 新连接，但继续处理已有请求直至完成
• 当连续多次 Worker 启动失败（如新配置有误），Master 会暂停重启，防止反复崩溃拖垮系统

配置生效与服务连续性并存

平滑过渡不是“切换”，而是“共存”——新旧 Worker 同时在线，职责明确：

• 新 Worker 启动后立刻使用新配置响应新建连接（如新 upstream、新 TLS 参数）
• 旧 Worker 仍按原配置处理存量连接，包括长连接、上传中请求、WebSocket 等，直到连接自然关闭或超时
• 日志轮转（USR1）、二进制升级（USR2）等操作也遵循同样逻辑：新旧进程各司其职，无中断、无丢连

配置变更的安全保障机制

避免因配置错误导致服务波动，Nginx 在多个层面做了防护：

• 配置文件替换推荐用 mv nginx.conf.new nginx.conf，依赖 rename() 系统调用的原子性，杜绝读到半截内容
• worker_rlimit_nofile 和 ulimit 设置需匹配，否则新 Worker 可能因无法打开足够文件描述符而启动失败
• master_process on 必须启用，禁用后将失去热重载、优雅退出、异常自愈等核心能力