nginx双机热备的核心是keepalived配合健康检查与热加载实现高可用：通过vrrp虚拟vip、脚本检测nginx状态、priority控制主备切换；配置更新需先备机reload再主机降优先级切换；后端动态感知依赖check模块、服务注册中心或dns解析；恢复后应延迟切回并灰度验证。
在 Nginx 双机热备（主备高可用）环境中，服务动态管理的核心不是靠 Nginx 自身实现故障切换，而是通过外部高可用机制（如 Keepalived）配合 Nginx 的健康检查与配置热加载能力，达成服务不中断、配置可更新、节点可平滑接管的效果。
Keepalived + Nginx 实现主备自动切换
Keepalived 是最常用的双机热备方案，它通过 VRRP 协议在两台 Nginx 服务器间虚拟出一个浮动 IP（VIP），由主节点对外提供服务；当主节点上的 Nginx 进程异常或机器宕机时，Keepalived 检测失败并触发 VIP 迁移至备机。
- 主备节点均需安装 Keepalived 和 Nginx，且 Nginx 配置保持一致（除监听地址等少量差异）
- Keepalived 配置中需定义 check_script，定期调用脚本检测 Nginx 工作状态（例如：curl -s http://127.0.0.1/health 或检查 nginx 进程是否存在）
- 优先级（priority）设置确保主节点默认抢占 VIP；备节点 priority 略低，并启用 nopreempt（非抢占模式）可避免脑裂
服务配置变更时的无缝热更新
修改 Nginx 配置后，不能 reload 全局影响连接，尤其在高并发场景下需确保已有请求不受干扰。Nginx 的 reload 本身是热更新机制，但需配合 Keepalived 的状态协同，避免 reload 瞬间主备同时不可用。
- 先在备机上修改配置并执行 nginx -t 校验语法，再 nginx -s reload；确认无误后再操作主机
- 若使用 Keepalived 主备模式，可在 reload 前临时降低主节点 priority，触发 VIP 切换到备机，完成主节点 reload 后再恢复 priority
- 对关键业务，建议配合 upstream 的健康检查（如 max_fails=2 fail_timeout=30s）和 proxy_next_upstream，提升单节点更新期间的容错能力
后端服务上下线的动态感知
当上游应用实例增减时，Nginx 本身不自动发现，需借助外部机制实现动态管理：
- 使用 nginx-upstream-check-module（需编译进 Nginx）开启主动健康检查，自动标记/摘除异常节点
- 集成 Consul 或 Nacos：通过 Lua 脚本（如 lua-resty-consul）或 OpenResty 的 balancer_by_lua* 阶段，实时拉取服务列表并更新 upstream
- 采用 DNS-based upstream（resolver + variable domain）：后端注册到私有 DNS，Nginx 定期解析域名更新 IP 列表（需注意 TTL 与缓存刷新策略）
故障恢复后的自动回归与流量控制
主节点恢复后是否立即切回，取决于业务容忍度。盲目切回可能引发瞬时流量冲击或状态不一致。
- Keepalived 支持 notify_master / notify_backup 脚本，在状态切换时执行自定义逻辑（如通知监控、触发灰度验证）
- 可在主节点恢复后延迟切回（如 sleep 60 && keepalived restart），或结合 readiness probe 判断后端服务真正就绪后再升 priority
- 上线前可通过 limit_req 或 geo+map 控制部分流量先导流至恢复节点，验证稳定性后再全量放开
不复杂但容易忽略的是：Keepalived 的检测粒度、Nginx reload 的时机协调、以及后端服务发现与 Nginx 配置生命周期的解耦。把这三者串起来，才能真正支撑起生产环境下的动态管理闭环。
