nginx主备仅实现入口层vip故障转移，不负责后端数据同步；后端一致性需数据库主从、redis哨兵、文件多副本等独立保障；必须端到端验证vip漂移与数据最终一致。
Nginx 本身不负责后端应用的数据同步，主备机之间的数据一致性需由后端服务（如数据库、文件系统或业务层）保障；Nginx 的“主备机故障转移”通常指负载均衡器入口层的高可用，即当一台 Nginx 机器宕机时，VIP（虚拟 IP）自动漂移到另一台，流量无缝切换——这和后端数据是否同步是两个层面的问题。
明确角色分工：Nginx 主备 ≠ 后端主备
常见误解是把 Nginx 主备当成“后端服务主备”。实际上：
- Nginx 主备（如 Keepalived 实现）只管谁来承接客户端请求，不干预后端数据怎么存、怎么同步；
- 后端数据同步（比如 MySQL 主从复制、Redis 哨兵、Elasticsearch 分片副本）必须由对应组件独立配置并验证；
- 只有当前端 Nginx + 后端数据同步都可靠，整个链路才算真正具备故障转移能力。
配置 Nginx 入口层主备（Keepalived + VIP）
这是实现“请求入口不中断”的核心。两台 Nginx 服务器部署完全相同的配置（含 upstream、proxy_pass、SSL 等），再通过 Keepalived 管理一个共享 VIP：
- 主节点 state MASTER，优先级设为 100；
- 备节点 state BACKUP，优先级设为 90；
- 配置 vrrp_script 检测本地 Nginx 进程是否存活（例如每 2 秒执行
curl -f http://127.0.0.1/health或检查systemctl is-active nginx）； - 检测失败时，用 weight -5 降低优先级，触发 VIP 漂移。
确保后端服务自身具备主备与同步能力
Nginx 把请求转给 upstream 后，能否成功处理，取决于后端是否真能“接得住”。所以必须同步落实：
- 数据库：MySQL 主从延迟需监控（
Seconds_Behind_Master ），写操作路由到主库，读可走从库（配合中间件或应用层逻辑）； - 缓存：Redis 使用哨兵（Sentinel）或 Cluster 模式，自动选主、故障转移；
- 文件存储：若用 NFS 或对象存储（如 MinIO、S3），确保多副本或跨机房同步策略已启用；
- 无状态服务：如 Java/Node.js 应用，本身无需同步，但 session 若依赖本地内存，需改用 Redis 或 JWT 等方案。
关键验证点：别只看 VIP 漂了没
上线前必须验证真实故障场景下的端到端可用性：
- 手动 kill 主 Nginx 进程，确认 VIP 在 3–5 秒内迁移到备机，且 curl VIP 返回正常响应；
- 在主 Nginx 恢复后，检查是否自动降为 BACKUP（非抢占模式下不应抢回 VIP）；
- 模拟后端某台 server 宕机，确认 upstream 的
max_fails=3 fail_timeout=30s和proxy_next_upstream能正确绕过它，并将请求发给健康节点； - 发起写请求（如提交表单），验证数据是否最终一致出现在所有从节点（查从库、查缓存、查文件副本）。
