nginx集群保障业务持续运行的核心是构建“故障可感知、切换可自动、恢复可闭环”的三层韧性体系：单机进程健壮性、节点间高可用协同、上游链路容错联动。
Nginx 集群要保障业务持续运行，核心不是堆机器，而是构建“故障可感知、切换可自动、恢复可闭环”的三层韧性体系：单机进程健壮性、节点间高可用协同、上游链路容错联动。
单机层面：靠 Master-Worker 多进程模型稳住自身
每个 Nginx 实例内部不依赖共享内存写操作，Worker 进程彼此隔离。一个 Worker 崩溃，Master 会毫秒级拉起新进程补位，不影响其他 Worker 正常处理请求；配置热重载（nginx -s reload）时，旧 Worker 继续服务存量连接，新 Worker 接管新连接，全程无中断。
- worker_processes auto; —— 自动匹配 CPU 核心数，避免争抢
- worker_rlimit_nofile 65535; —— 提升单进程文件描述符上限，支撑高并发
- accept_mutex on; multi_accept on; —— 减少惊群效应，提升连接接纳效率
节点层面：用 Keepalived + VIP 实现主备自动漂移
单台 Nginx 再稳定也扛不住整机宕机或网络中断。必须部署至少两台 Nginx 服务器，通过 Keepalived 管理同一个虚拟 IP（VIP）。主节点健康时对外提供服务；一旦心跳丢失（如 Nginx 进程退出、机器断电），备节点在 1 秒内 接管 VIP，客户端无感知切换。
- Keepalived 配置中需包含 vrrp_script 脚本，定期检查 nginx 进程存活（例如
killall -0 nginx） - 主备节点的 nginx.conf 和 upstream 列表必须完全一致，避免切换后路由错乱
- 推荐关闭 vrrp_strict（除非全网严格支持 VRRP 协议），减少环境兼容问题
上游层面：让 Nginx 主动识别并绕过异常后端
后端应用出问题不能让前端卡死。Nginx 必须具备主动探测能力，把“等超时再失败”变成“提前发现早隔离”。
- 每个 upstream server 加上 max_fails=2 fail_timeout=15s，连续失败即摘除
- 启用 proxy_next_upstream error timeout http_500 http_502 http_503 http_504，异常响应自动转发到下一节点
- 搭配后端统一暴露的 /health 接口（返回 200 OK），用第三方模块或脚本模拟主动健康检查
- 关键业务可设 backup 节点，仅当所有主节点失效时才启用，作为灾备兜底
会话与流量层面：防止用户请求被反复打散
登录态、购物车等强状态业务，不能因负载均衡导致会话丢失。IP 哈希是基础手段，但要注意适用边界：
- 局域网或 NAT 环境下，多个用户共用一个公网 IP，ip_hash 会失真，建议改用 cookie hash（需模块支持）或后端统一 Session 存储
- 若后端性能不均，ip_hash 不支持权重，可考虑一致性哈希（需 Plus 或第三方模块）
- WebSocket 或长连接场景，优先用 least_conn 算法，避免某节点堆积大量空闲连接
