Nginx 多进程架构如何支持高可用的双机热备部署

Nginx 多进程架构本身不提供双机热备，需与 Keepalived 配合实现：Master 进程守护 Worker，保障单机服务可用；Keepalived 通过 VRRP 和 HTTP 健康检查触发 VIP 漂移，实现主备切换；配置一致是前提，否则高可用失效。

Nginx 本身的多进程架构（Master + Worker 模型）并不直接提供双机热备能力，它解决的是单机内高可靠性和稳定性问题；而双机热备（主备自动切换）依赖的是外部机制——主要是 Keepalived 基于 VRRP 协议实现的 VIP 漂移。二者是协作关系：Nginx 的进程健壮性为“服务层可用”打底，Keepalived 则负责“网络层可用”和故障接管。

真正支撑高可用双机热备落地的，是 Nginx 多进程特性与 Keepalived 配合后形成的分层可靠性：

Master 进程不处理请求，只做调度与守护

Nginx Master 进程不响应客户端连接，只负责管理 Worker 进程生命周期、读取配置、平滑重启、日志轮转等。这意味着：

1. 即使某个 Worker 进程异常退出，Master 会立即拉起新进程，服务不中断
2. Master 自身极轻量、极少崩溃，大幅降低单机“假死但进程在”的概率
3. 这为 Keepalived 的健康检查（如 curl https://www.php.cn/link/fa01bbe3dc5821c4227e9e1d3c823e83 curl 能通，基本说明服务可响应

Worker 进程无状态、可快速重建

每个 Worker 是独立的事件驱动进程，不共享内存（除共享内存区外），彼此隔离。这带来两个关键优势：

1. 故障影响范围被限制在单个 Worker 内，不会蔓延至整个 Nginx 实例
2. 切换时无需同步会话或状态，备机上的 Nginx 启动即具备完整服务能力，与主机行为完全一致

与 Keepalived 健康检查形成闭环

单纯依赖进程存在（killall -0 nginx）不可靠，而 Nginx 的 HTTP 响应能力恰恰是最佳探测点：

1. 健康检查脚本（如 /etc/keepalived/nginx_check.sh）用 curl 访问本地 80 端口，本质是在验证 Master+Worker 协同工作的最终输出
2. 若返回 200，说明监听正常、配置加载成功、上游可达（如果是反代）、静态资源可读——这是端到端的服务健康信号
3. 一旦失败，Keepalived 降低本节点 priority，触发 VIP 漂移，把流量导向另一台同样具备该能力的 Nginx 实例

配置一致性是多进程发挥效用的前提

两台机器上 Nginx 必须做到：

1. 完全相同的 nginx.conf（含 listen、server_name、upstream、proxy_set_header 等）
2. 相同的 root 路径、证书文件位置、日志路径（便于排查）
3. 同样的启动方式（systemctl 或二进制命令）、同样的用户权限（如 nginx 用户）

   否则，即使进程都 running，切换后可能返回 502、跳错地址、或展示不同页面——多进程再稳也救不了配置偏差

不复杂但容易忽略