Nginx的Master-Worker架构更稳定，因进程隔离使故障边界清晰：Worker间内存独立，单个崩溃不影响其他进程；Master不处理业务，只负责配置解析、进程管理与信号调度，自身极简可靠。
Nginx 的 Master-Worker 架构不是简单的“多个进程一起干活”，而是一套职责明确、彼此隔离、协同稳定的运行体系。理解它，关键在于分清谁管事、谁干活、怎么容错、怎么扩容。
Master 进程：不碰请求的“总调度员”
Master 进程只做三类事：读配置、管 Worker、收信号。它从不处理客户端连接，也不参与 HTTP 解析或文件读写。启动时，它校验 nginx.conf 语法，初始化监听套接字（如 :80）、日志文件和模块；然后按 worker_processes 指令 fork 出指定数量的 Worker 进程；之后就进入休眠状态，只等待系统信号。
常见操作都靠发信号给 Master 实现：
- HUP：重载配置——先加载新配置，再拉起新 Worker，通知旧 Worker 处理完手头请求后退出
- USR2 + WINCH：平滑升级二进制——先启动新版 Master+Worker，再逐个关停旧 Worker
- USR1：重新打开日志文件——用于按天/按大小切割 access.log 或 error.log
- QUIT：优雅退出——所有 Worker 完成当前请求后终止，Master 再退出
Worker 进程：单线程、争抢式、无锁干活
每个 Worker 是一个独立的、单线程的 Unix 进程，采用异步非阻塞 I/O（如 epoll/kqueue）同时管理成千上万连接。它们之间不共享内存，也不通信，仅通过操作系统内核的事件通知机制“争抢”新连接——哪个 Worker 先调用 accept() 成功，这个连接就归它全权处理到底。
这种设计带来直接好处：
- 没有锁竞争：无需互斥量或原子操作协调资源，减少上下文切换和 CPU 空转
- 崩溃隔离：某个 Worker 因正则回溯、Lua 脚本错误或内存越界崩溃，只影响自身，其他 Worker 继续服务
- 快速恢复：Master 检测到 Worker 异常退出（如 exit code 非 0），立刻 fork 新进程补位，用户几乎无感
为什么用多进程，而不是多线程或单进程？
核心是兼顾稳定性、并发效率与硬件适配性：
- 比单进程强：单进程无法利用多核，高并发下容易成为瓶颈；多进程天然把负载分散到不同 CPU 核心
- 比多线程稳：线程共享地址空间，一个线程崩溃（如段错误）可能拖垮整个进程；进程间内存隔离，故障边界清晰
- 比纯事件循环更可控：像 Node.js 单线程模型虽轻量，但长耗时操作（如大文件同步读、阻塞 DNS 查询）会卡住整个服务；Nginx 的每个 Worker 独立，坏任务只卡住一个 Worker
- 资源分配灵活：可通过 worker_processes auto 自动匹配 CPU 核心数，也可设为固定值（如 4）配合 worker_cpu_affinity 绑定特定核心，避免缓存抖动
实际运行中你能观察到的现象
执行 ps -ef | grep nginx，通常看到类似结果：
root 1234 1 0 May25 ? 00:00:12 nginx: master process /usr/sbin/nginx
www-data 1235 1234 0 May25 ? 00:00:48 nginx: worker process
www-data 1236 1234 0 May25 ? 00:00:47 nginx: worker process
www-data 1237 1234 0 May25 ? 00:00:49 nginx: worker process
其中 PID 1234 是 Master，其余是它的子进程。如果手动 kill -9 一个 worker（如 1236），几秒内会出现新 PID 替代它——这就是容错机制在工作。
