Nginx多进程架构以可靠性为核心，通过主从职责分离、worker进程间内存隔离与无共享状态、异常时自动拉起新进程及平滑reload机制，实现单请求/单进程故障不影响整体服务。
Nginx 的多进程架构不是为了“堆并发”，而是把可靠性设计刻进运行机制里——它用职责分离、故障隔离和自动恢复三重机制，让单个请求出错不拖垮服务，单个进程崩溃不影响整体可用性。
主进程与工作进程严格分工
主进程（master）以 root 权限启动，只做四件事：读配置、绑定端口、管理 worker 进程、响应信号。它不处理任何网络请求，也不参与 I/O 或业务逻辑。所有 HTTP 请求、SSL 握手、静态文件读取、反向代理转发，全部交给普通权限的 worker 进程完成。这种分离带来两个关键保障：
- 主进程极轻量，几乎不会因业务异常崩溃；一旦它还在运行，整个服务就始终处于可调度状态
- worker 进程出问题（比如正则栈溢出、内存分配失败、第三方模块 bug），只会导致自身退出，不会污染主进程或其他 worker 的内存或连接状态
worker 进程彼此独立、无共享状态
每个 worker 是操作系统级独立进程，拥有专属的内存空间、连接队列、缓冲区、定时器和缓存索引。Nginx 默认不依赖共享内存（除 limit_req、limit_conn 等少数需协同的模块外），这意味着：
- 一个 worker 因慢请求、大文件传输或内存泄漏卡住，其他 worker 仍能正常接收并处理新连接
- 连接一旦被某个 worker 接收，后续整个生命周期（读、解析、转发、写回）都在该进程内闭环完成，不跨进程传递 socket
- 限流、缓存淘汰、连接超时等逻辑在进程内自治，无需加锁协调，避免死锁与竞争风险
崩溃后自动拉起 + 平滑 reload 机制
主进程持续监听 worker 存活状态。当检测到 worker 异常退出（如收到 SIGSEGV、被 OOM Killer 终止），会立即 fork 一个新进程补位，日志中仅记录类似 "worker process XXX exited on signal 11" 的信息，用户请求几乎无感知。
执行 nginx -s reload 时，主进程先验证新配置语法，再启动新 worker，并通知旧 worker 优雅退出（不再接受新连接，但继续处理已有请求）。即使新配置有误，主进程拒绝加载，旧 worker 继续运行——这本身就是一道关键容错防线。
配合系统级防护形成纵深保障
多进程是基础，但真正扛住生产环境压力还需组合策略：
- 用 systemd 或 supervisord 管理 master 进程，确保其意外退出后自动重启
- 在上游负载均衡层（如另一台 Nginx、HAProxy 或云 LB）配置健康检查，自动摘除失联实例
- 静态资源走 CDN，动态请求后端多实例部署，让 Nginx 不成为链路单点
- 通过 worker_rlimit_core 和 working_directory 配置 core dump 路径，便于事后精准定位崩溃根源
