Nginx 与 Keepalived 不能直接组合实现真正的异地多活集群，因其依赖的 VRRP 协议要求节点二层互通且延迟极低，仅适用于同城机房内高可用，跨地域需依赖 DNS 或 GSLB 等上层调度机制。
Nginx 与 Keepalived 不能直接组合实现真正的异地多活集群。Keepalived 依赖 VRRP 协议，而 VRRP 要求节点二层互通、延迟极低（通常
本地高可用：Keepalived 在单机房内保障 Nginx 入口不中断
每个机房内部署至少两台 Nginx 服务器（如 node-a 和 node-b），通过 Keepalived 共享一个本地虚拟 IP（VIP），例如 10.10.1.100：
- Keepalived 在该机房内运行 VRRP，由优先级决定 Master（绑定 VIP）和 Backup（监听心跳）
- Master 上的 Nginx 进程异常或机器宕机时，Backup 自动接管 VIP，实现秒级故障切换
- 必须配合自定义健康检查脚本（如 curl -f http://127.0.0.1/nginx_status），避免仅靠端口探测导致“服务假活”
跨地域流量调度：必须依赖 DNS 或 GSLB，而非 Keepalived
用户从不同地区访问 app.example.com，需要由上层系统决定返回哪个机房的 VIP：
- DNS 地理位置解析：阿里云云解析、Route 53 等根据用户出口 IP 所属地域，返回对应机房 VIP（北京用户 → 10.10.1.100，广州用户 → 10.20.1.100）
- GSLB 设备或云服务（如 Cloudflare Load Balancing）实时探测各机房健康状态、延迟、负载，动态返回最优入口 IP
- DNS TTL 必须设为较短值（建议 ≤60s），确保某机房故障后，用户能在一分钟内切走
Nginx 在多活中的真实角色：本地化路由与兜底转发
每个机房的 Nginx 不是全局决策者，而是区域入口网关，需承担本地化处理责任：
- upstream 配置中，本机房后端权重设高（如 weight=10），异地机房设低（如 weight=2），实现“本地优先、异地兜底”
- 启用主动健康检查（health_check interval=3 fails=2 passes=2），及时剔除不可用后端实例
- 透传 X-Real-IP 和 X-Forwarded-For，并添加自定义头（如 X-Region: beijing），供后端识别流量来源，做读本地缓存、写本地 DB 等差异化处理
数据层才是异地多活成败的关键
Nginx 和 Keepalived 都不解决数据一致性问题，但架构设计必须规避强依赖风险：
- 禁止跨机房两阶段提交等强一致事务，改用消息队列 + 补偿机制实现最终一致性
- 用户分片（如按 UID 取模）固定归属某机房，写操作只进归属地，读优先本地，失败再查异地
- 配置类、开关类共享数据，统一走 Apollo 或 Nacos 等分布式配置中心，不靠 reload 同步
