Nginx通过master-worker多进程架构实现自动故障恢复：master仅负责调度且极稳定，worker间隔离，任一worker崩溃后master秒级拉起新进程，全程无需外部工具干预。
Nginx 的多进程架构本身不靠外部工具，而是通过主进程（master）与工作进程（worker）的天然分工，实现故障发生后的自动恢复。核心在于：一个 worker 崩了，master 立刻补上，其他 worker 继续干活，用户基本感觉不到。
主进程只管调度，不碰请求
master 进程不处理任何 HTTP 请求、不读文件、不建连接。它只做四件事：读配置、绑定端口、拉起 worker、监听 worker 存活状态。正因为职责极轻，它极少崩溃；即使某个 worker 因内存越界、第三方模块 bug 或极端请求挂掉，master 仍稳如磐石，继续监控和调度。
Worker 进程彼此隔离，互不影响
每个 worker 是独立的 OS 进程，拥有自己的内存空间、文件描述符和连接队列。这意味着：
- 一个 worker 被 OOM Killer 杀掉或触发段错误（SIGSEGV），其他 worker 完全不受影响，照常响应新请求
- 某个 worker 正在处理慢查询或大文件下载，不会阻塞其他 worker 接收和分发连接
- 可通过
worker_rlimit_core和working_directory单独设置 core dump 路径，出问题时精准定位是哪个 worker、哪类请求导致的
Master 自动检测并拉起新 worker
master 用 waitpid() 持续监听子进程退出状态。一旦发现某个 worker 非正常退出（比如返回码非 0），它会：
- 在 error.log 中记录具体信号和 PID，例如
"worker process 12345 exited on signal 11" - 立即检查当前活跃 worker 数量是否低于
worker_processes配置值 - 若不足，调用
fork()启动一个全新 worker，继承原有监听套接字和配置，无缝加入服务队列
这个过程完全由 Nginx 内部完成，无需 systemd、supervisord 或脚本干预，通常在 1 秒内完成。
需要额外防护的边界情况
虽然 worker 层已自带恢复能力，但生产环境还需兜底：
- master 进程自身崩溃无法自愈，必须由 systemd 设置
Restart=always和RestartSec=3保障整实例重启 - 避免配置错误导致反复启动失败，应在 systemd 中加
ExecStartPre=/usr/sbin/nginx -t校验配置 - 对高负载场景，限制资源防雪崩：
MemoryMax=1G、LimitNOFILE=65535（systemd v240+）
不复杂但容易忽略
