Nginx采用主从进程模型：1个master进程以root权限管理配置、信号和worker生命周期，多个worker进程以非root用户通过事件驱动模型处理请求；二者分工明确，协同实现高性能与高可靠性。
Nginx 启动后并非只运行一个进程，而是采用“主从”分工模式：一个 master 进程 负责全局管理与信号调度，多个 worker 进程 实际处理网络请求。理解二者关系，是高效配置、调优和排障的基础。
master 进程：不干活但管全局
master 进程以 root 权限启动（便于绑定 80/443 等特权端口），它本身不处理 HTTP 请求，主要职责包括：
- 读取并校验 nginx.conf 配置，确保语法正确、路径可访问
- 创建监听 socket（如 0.0.0.0:80），然后交由 worker 进程继承使用
- 派生、监控、重启 worker 进程（如 worker 异常退出，master 会拉起新进程）
- 响应管理员信号（如 reload、stop、reopen），安全地完成配置热更新或日志轮转
正常运行中，master 进程 CPU 和内存占用极低，通常只有一个，且 PID 固定（即 nginx.pid 文件中记录的 ID）。
worker 进程：真正干活的“工人”
worker 进程由 master 派生，以非 root 用户（如 www-data 或 nginx）身份运行，直接响应客户端请求。关键特性包括：
- 每个 worker 是独立的单线程进程，采用事件驱动（epoll/kqueue）模型，可同时处理成千上万连接
- 默认数量由
worker_processes auto;决定（通常等于 CPU 核心数），也可手动设为固定值（如worker_processes 4;） - worker 之间不共享内存，彼此隔离；session、缓存等需借助外部服务（如 Redis）实现跨 worker 一致性
- 可通过
worker_connections控制单个 worker 最大并发连接数（需结合系统 ulimit 调整）
常用进程管理操作与信号含义
所有操作均通过向 master 进程发送信号完成，切勿 kill -9 worker 进程（会导致连接中断、状态不一致）：
-
nginx -s reload→ 发送SIGHUP：master 重新加载配置，平滑启动新 worker，逐步关闭旧 worker（处理完已有请求后退出） -
nginx -s stop→ 发送TERM：master 立即通知所有 worker 退出，自身随后终止（快速停止，可能丢请求） -
nginx -s quit→ 发送QUIT：master 通知 worker 完成当前请求后再优雅退出，更安全 -
kill -USR1 $(cat /var/run/nginx.pid)→ 重开日志文件（用于 logrotate） -
kill -USR2 $(cat /var/run/nginx.pid)→ 平滑升级二进制（配合新版 nginx 替换后执行）
排查与验证技巧
快速确认当前进程状态：
-
ps aux | grep nginx：查看 master（带 “master process”）和 worker（带 “worker process”）进程及其用户、启动时间 -
cat /var/run/nginx.pid：获取 master 进程 PID（路径以实际配置中pid指令为准） -
lsof -i :80或ss -tlnp | grep :80：确认监听 socket 是否由 worker 进程持有（应显示多个 worker 的 PID） - 观察
error.log：worker 异常退出时，master 会在 error.log 中记录 “worker process XXX exited on signal XX”
不复杂但容易忽略：worker 进程数不是越多越好——过多会导致上下文切换开销上升，尤其在高并发 I/O 场景下反而降低吞吐。建议从 auto 开始，结合 ab 或 wrk 压测调整。
