单纯用Nginx默认轮询在多数据中心场景下无法实现真实流量均摊，因其不感知延迟、带宽与负载差异；需结合weight映射物理能力、upstream_hash保障会话亲和、proxy_next_upstream与健康检查提升韧性，并建议DNS层GSLB前置解耦。
单纯用 Nginx 默认轮询在多数据中心场景下容易“看起来均匀、实际失衡”——它只按配置顺序发请求，不看网络延迟、机房带宽或节点实时负载。北京和广州各部署3台服务器，若直接等权轮询，很可能广州因链路抖动、出口带宽小，响应变慢甚至超时，而北京资源闲置。
权重设置要反映真实承载力
轮询本身不感知物理差异，必须靠 weight 把逻辑调度映射到实际能力上：
- 按出口带宽比例设权：比如北京机房总带宽是广州的1.7倍，可设北京每台 weight=10，广州每台 weight=6，总权重比≈40:12→约77%:23%
- 搭配 max_fails=3 fail_timeout=30s，自动隔离短时异常节点，避免单台故障拖累整机房流量承接
- 权重是静态预估，适合业务波动平稳的场景；若需动态适配，得借助 Lua 脚本或 Nginx Plus 的 status API
会话亲和不能靠轮询保障
用户登录态、文件上传路径、本地缓存等依赖固定机房时，强制路由比平均更重要：
- 用 hash $remote_addr consistent 做一致性哈希，让同一客户端始终落在同一台后端，增减节点时漂移最小
- hash 和 weight 可共存：hash 决定“去哪台”，weight 影响“各机房整体分多少”，两者协同才能既稳又匀
- 避免用 $request_uri 这类易变变量做 hash，否则一次页面刷新就可能跳到另一机房
健康检查必须主动+容错双驱动
跨数据中心网络不稳定，仅靠轮询跳过 down 节点远远不够：
- 开启 proxy_next_upstream error timeout http_500–504，一次失败立即换节点，防慢请求堆积
- 启用主动健康检查（如 health_check interval=5 fails=2 passes=2），定期探测各节点可用性
- 对弱链路机房（如广州），可调高 fail_timeout 至60秒，避免因瞬时 RT 高被误摘
更稳妥的解耦思路是 DNS 层前置
当机房间延迟差异大、抖动频繁时，把调度决策前移到 DNS 层更可靠：
- 用 GSLB（如 PowerDNS + GeoIP）按用户地理位置解析：北京用户→bj.example.com，广州用户→gz.example.com
- Nginx 只负责各自机房内部的轮询或加权轮询，彻底规避跨机房调度难题
- 该方案故障隔离强、运维边界清晰，适合 SLA 要求高的生产环境
