Nginx多进程架构通过worker独立性、upstream去中心化健康检查、连接绑定与超时控制，实现后端故障的局部化隔离与自动恢复；master轻量调度，配合systemd实现进程级兜底。
Nginx 多进程架构本身不直接处理后端服务故障，但它为反向代理层的故障隔离与恢复提供了坚实基础——真正的后端故障应对，依赖于 upstream 配置与 worker 进程协同工作的机制。
worker 进程天然互不干扰
每个 worker 是独立进程，拥有自己的内存空间、连接池和计时器。当某个后端节点不可用时：
- 仅当前处理该请求的 worker 可能触发超时或错误，其他 worker 仍可正常接收新连接、转发请求
- 不会因一个后端响应慢或断连，导致整个 Nginx 停摆或所有请求排队等待
- 即使某个 worker 因异常退出（如段错误），master 进程会立即拉起新 worker，其余 worker 完全不受影响
upstream 健康管理由每个 worker 独立执行
被动健康检查（max_fails / fail_timeout）不是全局统一判断，而是每个 worker 维护自己的失败计数器：
- 某 worker 连续几次访问 backend-A 失败，它会将 backend-A 标记为“暂时不可用”，后续请求不再发给它
- 其他 worker 若尚未累积足够失败次数，仍可能继续尝试 backend-A —— 这种“去中心化”判定避免了单点误判，也提升了恢复灵敏度
- 配合 proxy_next_upstream error timeout http_502 http_503，worker 在遇到异常时自动换节点重试，无需等待全局状态同步
连接绑定 + 超时控制防止故障扩散
一个请求从 accept 到响应完成，全程绑定在单个 worker 内处理：
- proxy_connect_timeout 限制建连时间，避免卡在 TCP 握手阶段拖住整个 worker
- proxy_read_timeout 控制等待后端数据的时间，超时即中断并重试，不阻塞后续请求
- keepalive 复用连接可减少建连失败概率，但复用本身也受单 worker 连接池限制，不会跨进程共享失效连接
systemd 与 master 协同兜底
当故障升级到 Nginx 自身层面（如配置错误、OOM、磁盘满），多进程结构需外部保障：
- master 进程极轻量，只做调度，几乎不参与业务逻辑，崩溃概率低
- systemd 设置 Restart=always 和 RestartSec=3，确保 master 意外退出后秒级重启
- ExecStartPre=/usr/sbin/nginx -t 强制启动前校验，避免错误配置反复拉起失败进程
