nginx多进程架构通过职责隔离、单点控制与无共享设计实现稳定协作：master为唯一协调者，worker彼此独立、零耦合；协作依赖信号驱动（如sighup/sigquit）、原子文件替换保障配置一致性，以及共享内存配轻量锁（ngx_shmtx_t）用于运行时状态同步，而非进程间强依赖或运行时通信。
Nginx 的多进程架构并不依赖传统意义上的“进程间依赖管理”，它刻意规避了进程间强依赖，转而通过职责隔离 + 单点控制 + 无共享设计实现稳定协作。所谓“管理依赖”，实质是控制哪些进程该做什么、何时做、如何交接，而不是让 Worker 彼此调用或等待。
Master 是唯一协调者，Worker 之间零耦合
Master 进程承担全部调度与协调职责，Worker 进程彼此完全独立：
- 每个 Worker 启动时复制一份只读配置副本，运行中不读取外部状态，也不向其他 Worker 发送消息
- Worker 之间不共享连接、不转发请求、不协商负载，更不会因某个 Worker 故障而影响其他 Worker 的运行
- 所有跨进程动作（如 reload、退出、崩溃恢复）均由 Master 主动发起并控制节奏，Worker 只响应信号，不主动触发协作
进程协作靠信号与文件系统，而非运行时通信
Nginx 避免在 Worker 间建立复杂通信通道，关键协同机制如下：
- 信号驱动生命周期：SIGHUP 由 Master 解析后触发 fork 新 Worker；SIGQUIT 由 Master 发送给旧 Worker，通知其完成当前请求后退出
-
原子文件替换保障配置一致性：新配置写入临时文件再
mv替换，Master 总是读取最新 inode，Worker 在 fork 时已固化配置，不存在运行时读取冲突 -
共享内存仅用于特定场景，且自带轻量同步：如
limit_req_zone使用的共享内存区，由ngx_shmtx_t锁保护，但该锁不参与配置加载，只服务于运行时计数等有限状态
Cache 进程与 Worker 的协作是特例，但仍受 Master 统一编排
Cache Loader 和 Cache Manager 进程虽与 Worker 共享缓存数据，但：
- 它们由 Master 统一启动和监控，不与 Worker 建立直接调用关系
- 缓存数据通过共享内存段访问，Worker 读取时无需加锁（只读），写入由 Cache Manager 控制，避免并发修改
- Cache Loader 仅在启动阶段批量载入磁盘缓存，之后不再活跃；Cache Manager 定期清理过期项，行为由 Master 配置参数约束
崩溃恢复靠 waitpid 非阻塞回收，不依赖进程间状态同步
Master 通过 waitpid(-1, &status, WNOHANG) 周期性检查子进程退出：
- 一旦发现某 Worker 异常终止（如段错误），立即 fork 新进程补位，不等待其他 Worker 状态
- 退出原因仅用于日志记录和统计，不触发连锁反应或状态重同步
- 新 Worker 启动后直接接管监听 socket，旧连接由原 Worker 继续处理完毕，无状态迁移负担
本质上，Nginx 不管理“依赖”，而是消除依赖——把协作压缩成信号、文件、共享内存这三类边界清晰、开销可控的交互方式。
