nginx服务启动由master主导、worker协同，master先校验配置、预建监听套接字、按worker_processes派生worker；worker继承套接字并借accept_mutex避免惊群；master与worker通过socketpair和信号双向通信，异常时自动拉起新worker；cache loader和cache manager由master按需启动并统一监管。
Nginx 多进程架构的服务启动不是简单拉起几个进程，而是由 master 进程主导、worker 进程协同、信号与共享机制共同保障的一套有序流程。
master 进程先行初始化并统筹全局
服务启动时，首个进程即为 master。它不处理请求，只做三件事：加载并校验 nginx.conf 配置；预分配监听 socket（如 80/443 端口）；根据 worker_processes 指令决定要 fork 出多少个 worker 子进程。配置若存在语法错误，master 会在这一阶段直接退出，整个服务启动失败。
worker 进程按需派生，共享监听套接字
master 调用 ngx_spawn_process 创建 worker 进程，所有 worker 都继承 master 已创建的监听 socket。这意味着多个 worker 实际上“共用”同一个端口——但不会同时抢 accept 连接，因为：
- 默认启用 accept_mutex（锁机制），确保任一时刻仅一个 worker 在阻塞等待新连接；
- 锁实现依赖操作系统：支持原子整型时用共享内存锁，否则退化为文件锁；
- 该机制有效避免“惊群效应”，防止大量空唤醒消耗 CPU。
进程间通过信号与 socketpair 实现双向管控
启动完成后，master 和 worker 并非各自为政，而是持续通信：
- master 向 worker 发送指令（如重载配置、平滑升级）通过 socketpair（Unix 域套接字），可靠且低开销；
- worker 向 master 报告状态（如异常退出）通过标准信号，例如 SIGCHLD；
- 当某个 worker 崩溃，master 收到 SIGCHLD 后立即检查并重新 fork 一个替代进程，维持设定的 worker 数量不变。
配套进程按需激活，统一受控于 master
除核心 worker 外，Nginx 还可能启动两类辅助进程，它们同样由 master 启动和监管：
- cache loader：仅在 Nginx 首次启动时运行，负责将磁盘上的缓存索引文件加载进共享内存，完成即退出；
- cache manager：长期运行，周期性清理过期缓存、控制缓存大小，响应 master 的 reload 或 stop 指令。
这两类进程不参与请求处理，但它们的存在让缓存功能具备自管理能力，且不干扰主服务流程。
