异地多活的全局负载均衡需DNS/GSLB、Nginx、数据层三层协同：第一层DNS/GSLB按地域与健康状态调度流量；第二层Nginx实现机房内智能路由与容错；第三层通过分片、消息队列和多活同步保障数据最终一致。
异地多活的全局负载均衡，本质不是让 Nginx 或 Keepalived 跨城市选主，而是分层协作：DNS/GSLB 做机房级调度，Nginx 做机房内精细转发，数据层保障最终一致。单靠接入层配置无法达成多活，必须三层对齐。
第一层：DNS 或 GSLB 实现跨地域入口分流
客户端访问域名（如 app.example.com）时，请求最先到达的是 DNS 解析系统，这一层决定流量去哪个城市机房：
- 使用支持地理位置+健康探测的 DNS 服务（如阿里云云解析、AWS Route 53、火山引擎 GTM），根据用户出口 IP 所属地域返回对应机房的 VIP（例如北京用户→10.10.1.100，深圳用户→10.30.1.100）
- 必须开启主动健康检查：不只是 ping 端口，而是从多个探测点发起真实 HTTP 请求（如 GET /health），验证 Nginx + 后端链路整体可用性
- DNS TTL 设为 60 秒以内，确保某机房异常后，用户能在 1–2 分钟内自动切换到其他可用节点
第二层：各机房 Nginx 集群承担本地化路由与容错
每个机房部署至少两台 Nginx（配合 Keepalived 实现 VIP 漂移），它不负责“跨城决策”，但需支撑本机房内的弹性与智能：
- upstream 中定义本机房服务（高权重，如 weight=10）和异地备用服务（低权重，如 weight=2），启用 proxy_next_upstream error timeout http_502，实现后端故障自动摘除与重试
- 通过 map 模块提取 X-User-ID 或 cookie，做 consistent hash 路由，保证同一用户始终落在同一机房，适配用户分片策略
- 对写请求（如 POST /api/submit）固定转发至主写机房；读请求（如 GET /api/profile）优先本机房，失败再 fallback 到异地上游
第三层：数据与状态协同是成败关键
流量能分过去，不代表业务能稳住。Nginx 和 DNS 只是“手”，真正起作用的是背后的数据逻辑：
- 禁止跨机房强一致性事务（如分布式锁、两阶段提交），改用消息队列（Kafka/RocketMQ）+ 补偿任务实现最终一致
- 用户数据按 UID 分片，写操作只进归属机房；全局缓存（如 Redis）采用多活同步方案（如腾讯会议的 Redis 分库+双写+冲突解决）
- 所有机房 Nginx 日志中透传 X-Region 头，便于后端识别来源、做本地缓存命中或降级策略
不复杂但容易忽略：全局负载均衡不是配置堆叠，而是 DNS 的感知力、Nginx 的适应力、数据层的收敛力三者咬合的结果。少一层，就只是“多地部署”，不是“异地多活”。
