nginx负载均衡高可用需三层协同：负载均衡层选合适算法（加权轮询/ip_hash/least_conn）、配置主动健康检查与超时；后端服务层部署多实例、共享redis会话、数据库主从容灾；nginx自身通过keepalived双机热备+vip实现秒级故障切换。
要让 Nginx 负载均衡真正支撑起业务的高可用与灾备，不能只配个 upstream 就完事。核心是三层协同：流量分发层可靠、后端服务层自愈、基础设施层冗余。下面从三个关键维度讲清楚怎么做。
一、负载均衡层：选对算法 + 健康检查 + 故障自动剔除
默认轮询不够用，必须按业务特征选策略：
-
无状态 API 或静态资源：用加权轮询（
weight），按服务器 CPU/内存实际能力分配流量，比如新机器设weight=5，老机器设weight=2 -
需会话保持的后台系统（如监控平台登录态）：启用
ip_hash，但注意后端扩缩容时会重哈希，建议搭配 Redis 共享 Session，避免单点依赖 -
长连接类服务（如 WebSocket 接入层）：用
least_conn，优先把新连接导给当前连接数最少的节点
健康检查必须显式配置，不能靠默认被动机制：
- 每台后端加
max_fails=3 fail_timeout=30s，连续失败 3 次就隔离 30 秒 - 生产环境建议编译或启用
nginx_upstream_check_module，实现主动 HTTP 探活（如 GET /health），响应 200 才认为存活 - 在
proxy_pass前加上超时控制：proxy_connect_timeout 5s; proxy_read_timeout 60s;，防慢后端拖垮 Nginx
二、后端服务层：多实例 + 会话共享 + 数据库容灾
Nginx 只是入口，后端不稳，再好的负载均衡也白搭：
- Komari 类应用需部署至少 2 个独立实例（如
192.168.1.101:8080和192.168.1.102:8080），启动时指定不同配置文件，避免单配置故障全崩 - 所有实例必须共用同一套会话存储，推荐 Redis：
config.Set("session.provider", "redis")，地址指向高可用 Redis 集群（非单点） - 数据库必须主从分离，Komari 的
dbcore.go中启用"failover": true，并配置master和slave地址；同时每天定时备份，命令写进 crontab：0 3 * * * /usr/local/bin/komari backup --db --output /backup/komari_$(date +\%Y\%m\%d).sql
三、Nginx 自身高可用：Keepalived 双机热备 + VIP 切换
Nginx 本身不能单点存在，否则它挂了整个流量就断了：
- 在两台 Nginx 服务器上都装
keepalived，配置相同虚拟 IP（VIP，如192.168.1.200），客户端只访问这个 VIP - 主节点
priority 101，备节点priority 99；用vrrp_script每 2 秒检查nginx进程是否存在，挂了就降权触发切换 - 网卡名（如
ens160）、虚拟路由 ID（virtual_router_id）两台必须一致，且不能与其他 VRRP 冲突 - 切换时间实测通常在 3–5 秒内，对用户基本无感；切换后原主恢复，不会自动抢回 VIP，避免震荡
不复杂但容易忽略：所有配置文件（Nginx conf、Keepalived conf、Komari config.go、dbcore.go）都要纳入版本管理，并定期备份到异地；每次变更先在测试环境验证 VIP 切换和后端剔除逻辑是否生效。
