怎样理解 Nginx 的 Master 与 Worker 进程架构

Nginx采用Master-Worker多进程架构：Master进程以root权限负责配置加载、监听套接字创建及Worker生命周期管理，不处理请求；Worker进程以非root权限单线程运行，通过epoll异步非阻塞I/O争抢连接并独立处理，内存隔离保障稳定性。

理解 Nginx 的 Master-Worker 架构，核心是抓住“谁管事、谁干活、怎么不出乱子”这三点。它不是简单起多个进程，而是一套分工极明确、故障有边界、扩容有依据的运行体系。

Master 进程：不碰请求的总调度员

Master 进程以 root 权限启动，但自己从不处理任何客户端连接或 HTTP 逻辑。它只干三类事：

• 读配置、验语法：启动时解析 nginx.conf，检查路径权限、端口占用、模块加载是否正常
• 建监听套接字：提前 bind() 和 listen() 到 80/443 等端口，再把已就绪的 socket 句柄交给 Worker 继承使用
• 管 Worker 生命周期：按 worker_processes 指令 fork 出指定数量的 Worker；持续监控它们的状态，异常退出时立刻补一个新进程

它长期处于休眠状态，只等信号唤醒——比如 SIGHUP（重载配置）、USR1（重新打开日志）、QUIT（优雅退出）。它的 PID 固定，记录在 nginx.pid 文件里，日常 CPU 和内存开销几乎为零。

Worker 进程：单线程争抢式干活的工人

每个 Worker 是一个独立的 Unix 进程，以非 root 用户（如 www-data）运行，真正响应请求。关键特点是：

• 单线程 + 异步非阻塞 I/O：用 epoll（Linux）或 kqueue（BSD）同时管理数万连接，不靠多线程抢资源
• 无锁争抢连接：所有 Worker 同时调用 accept()，内核决定哪个先拿到新连接，拿到就全权处理到底
• 内存完全隔离：崩溃只影响自身，不会波及其他 Worker，也不会拖垮整个服务

默认数量通常设为 worker_processes auto;，自动匹配 CPU 核心数；也可手动固定（如 worker_processes 4;），配合 worker_cpu_affinity 绑核提升缓存命中率。

为什么选多进程，而不是多线程或单进程？

这是兼顾稳定性、并发效率与硬件特性的权衡结果：

• 比单进程强：单进程无法并行利用多核，高并发下容易成为瓶颈；多进程天然分散到不同 CPU 核心
• 比多线程稳：线程共享地址空间，一个段错误可能让整个进程挂掉；进程间内存隔离，故障边界清晰
• 比纯事件循环更可控：像 Node.js 单线程模型一旦遇到阻塞操作（如同步文件读、DNS 查询），整个服务就卡住；Nginx 每个 Worker 独立，坏任务只卡住一个 Worker

常见操作都靠信号驱动，不是 kill -9

所有运维动作都通过向 Master 进程发信号完成，切忌直接杀 Worker：

• nginx -s reload → 发 SIGHUP：Master 加载新配置，拉起新 Worker，通知旧 Worker 处理完当前请求后退出
• nginx -s quit → 发 SIGQUIT：Worker 完成手头请求再退出，最安全的停服方式
• nginx -s stop → 发 SIGTERM：立即终止所有 Worker，速度快但可能丢请求
• kill -USR1 `cat /var/run/nginx.pid` → 重新打开 access.log/error.log，配合日志轮转脚本使用

这种设计让配置变更、日志切割、平滑升级等操作全程无感知，用户请求不中断。