保障Nginx集群高可用需三层面协同：Upstream层通过主动健康检查、智能调度算法与超时设置实现秒级故障隔离；后端层统一健康端点、外置Session及数据库主从分离；Nginx自身采用Keepalived+VIP双机热备，并辅以可观测性与应急兜底机制。
保障 Nginx 集群架构中业务流量的高可用性，关键在于打破单点依赖、实现故障自动感知与秒级切换。不能只靠 upstream 轮询，而要从流量入口、后端协同、自身冗余三个层面同步加固。
Upstream 层：精准调度 + 主动健康检查
默认轮询不具备状态感知能力，必须叠加主动探测和智能策略：
- 按业务选算法：无状态 API 用加权轮询（weight），会话类系统启用 ip_hash（但需搭配 Redis 共享 Session 避免扩缩容抖动），长连接服务（如 WebSocket）优先 least_conn
- 每台后端显式配置 max_fails=3 fail_timeout=30s，30 秒内连续失败 3 次即隔离；建议编译或启用 nginx_upstream_check_module，通过 GET /health 主动探活，响应 200 才视为健康
- proxy_pass 前必须设超时：proxy_connect_timeout 5s 控制建连，proxy_read_timeout 60s 防止慢响应拖垮 Nginx
- 预留 backup 节点：仅当所有主节点不可用时才启用，适合部署灾备实例或低配兜底服务
后端服务层：统一就绪态 + 状态解耦
Nginx 再可靠，后端不稳也白搭。高可用链路的前提是后端能自证健康：
- 所有应用必须暴露标准健康端点（如 /health 或 /actuator/health），返回 HTTP 200 且 body 含 "status":"UP"
- 禁止将健康检查指向业务接口（如 /api/order），避免因业务延迟或临时错误误判宕机
- 会话状态必须外置：使用 Redis 集群（非单点）统一管理 session，确保请求被任意实例处理都不丢失上下文
- 数据库必须主从分离，并在应用层开启 failover 开关；定期备份脚本写入 crontab，例如每天凌晨 3 点执行全量导出
Nginx 自身高可用：Keepalived + VIP 双机热备
Nginx 本身不能成为单点。两台服务器共用一个虚拟 IP（VIP），客户端始终访问 VIP：
- 主节点 priority 设为 101，备节点设为 99；通过 vrrp_script 每 2 秒检测 nginx 进程是否存在，挂掉即降权触发切换
- VIP 绑定在物理网卡（如 ens160）上，主备配置中 virtual_router_id 必须一致，确保 VRRP 协议正常协商
- 两台 Nginx 的配置文件（nginx.conf 和 upstream 列表）需完全同步，包括 SSL 证书、日志路径、proxy 参数等
可观测性与应急兜底
高可用不只是“不挂”，更是“挂了也能快速恢复”：
- 接入 Prometheus + Grafana，监控 upstream 状态码分布、失败率、连接数、响应延迟等核心指标
- 对 5xx 错误、健康检查失败、VIP 切换事件设置企业微信/钉钉告警，响应时间控制在 5 分钟内
- 关键接口启用幂等重试（如 proxy_next_upstream error timeout http_502；最多 retry 2 次），避免单次失败直接返回错误
