nginx master进程不处理请求，仅负责配置校验、创建监听套接字、fork worker进程，并通过信号机制（sighup/sigquit/sigusr1/sigusr2）协调worker；worker继承监听句柄、以降权运行、专注i/o与业务，借助accept_mutex避免惊群，日志由master统一落盘，worker异常时master自动重启新进程保障服务连续性。
Nginx 的 Master Process 本身不处理请求，它的存在是为了让多个 Worker 进程能稳定、高效、安全地协同工作。这种协作不是靠复杂通信，而是靠轻量、明确的分工与约定好的信号机制实现的。
Master 负责“建好舞台”，Worker 负责“上台演出”
Master 启动时就完成三件关键准备动作：校验配置、创建监听套接字（bind + listen）、按 worker_processes 数量 fork 出 Worker 进程。所有 Worker 都继承或共享这些已就绪的监听句柄——它们一启动就能直接 accept 新连接，无需重复初始化。
这意味着：
- Worker 不需要自己解析配置，也不用抢着 bind 端口，避免冲突和重复开销
- Master 始终持有 root 权限，而 Worker 以普通用户（如 www-data）运行，降低安全风险
- 监听套接字由 Master 统一管理，Worker 只专注 I/O 多路复用和业务逻辑
信号驱动，各司其职不越界
Master 和 Worker 之间不共享内存做状态同步，也不用 socket 或消息队列通信，而是通过 Unix 信号达成默契：
- SIGHUP：发给 Master，触发配置重载流程；Master 启动新 Worker，再通知旧 Worker 优雅退出
- SIGQUIT：可发给 Master（优雅关机）或 Worker（单独退出），Worker 收到后不再接受新连接，处理完存量请求后自行终止
- SIGUSR1：发给 Master，让它重新打开 access/error 日志文件（常用于日志轮转）
- SIGUSR2：配合二进制升级，Master 启动新版本进程，逐步切换流量
每个信号含义固定，Worker 不会响应 SIGHUP，Master 也不会响应 SIGQUIT —— 协作建立在角色隔离基础上。
连接分发与资源协调靠“软约束”，不是硬锁
为防止多个 Worker 同时被唤醒争抢 accept（即“惊群”），Nginx 默认启用 accept_mutex on。但这不是传统互斥锁，而是 Master 在内核事件循环中做一次原子判断：只允许一个 Worker 尝试 accept，其余等待下一轮事件就绪。
日志写入也体现分层思想：Worker 把日志内容写入 pipe 或共享内存区，由 Master 统一落盘。这样既避免多进程并发刷磁盘，又保证日志顺序性和一致性。
故障隔离与自动恢复是协作的底线保障
Master 持续监听 SIGCHLD 信号，一旦某个 Worker 异常退出，立刻 fork 一个新的补上，保持 worker_processes 数量恒定。而 Worker 崩溃不会中断已有连接——那些连接仍在其他正常 Worker 中继续处理，用户无感知。
这种设计让系统具备天然容错能力：Master 是单点但极轻量，Worker 是多实例但彼此独立。只要 Master 还在，整个服务就能持续运转并自我修复。
