nginx权重调度核心是按实际承载力分摊流量，需将正整数weight置于upstream的server行中（仅对round_robin和ip_hash生效），配合max_fails、fail_timeout、backup/down等参数实现混合云环境下的差异化容错与路由协同。
Nginx 权重调度在混合部署环境里，核心是让不同来源、不同能力的后端节点（比如本地 IDC、阿里云、AWS）按实际承载力分摊流量，而不是平均瓜分。它不是简单调个数字，而是要和健康探测、路由策略、服务契约协同工作。
权重必须写在 upstream 的 server 行里，且只对 round_robin 和 ip_hash 生效
- 正确写法：
server 10.1.1.10:8080 weight=5; - 错误写法：把
weight=写在 location 块里，或单独成行，Nginx 会直接报错unknown directive "weight" - 权重值只能是正整数，默认为 1；设为 0 表示该节点不参与轮询，但仍接受健康检查（可用于灰度观察）
按节点类型差异化设权，兼顾性能与容错
- 本地 IDC 节点：内网直连、延迟低，可设
weight=5，max_fails=2，fail_timeout=10s，故障响应快 - 阿里云节点：走公网或 SLB，稳定性中等，建议
weight=3，max_fails=3，fail_timeout=15s，避免因短暂抖动误剔 - AWS 跨区域节点：链路长、成本高，适合兜底，
weight=2，fail_timeout=20s，防止频繁切换
权重配合状态标记，应对真实运维场景
-
backup：仅当所有非 backup 节点不可用时才启用，比如把 AWS 节点标为backup，作为灾备通道 -
down：强制摘除，不参与任何调度（包括健康检查），适用于计划维护 - 注意：
ip_hash下backup节点不参与哈希计算，但会在其他节点全失效时启用；而round_robin中backup仍计入权重分配逻辑（只是默认不启用）
权重不等于精确比例，需结合业务特征选路由方式
- 权重影响的是请求概率分布，小流量下可能连续打到高权节点，属正常行为；统计上百次请求后才接近理论比（如 weight=3 和 weight=1 接近 3:1）
- 若业务有状态（如登录态、购物车），单纯轮询+权重会导致会话丢失，应叠加：
-
hash $cookie_sessionid：依赖应用透传统一 session ID -
map+ 请求头分流：如识别X-Cloud-Preference: aliyun，定向转发 - 单独
location匹配路径：如/api/v2/sync/固定走阿里云 upstream
-
前置保障比权重配置更关键
- 所有后端必须提供一致的 API 接口路径、参数格式、响应结构和状态码语义
- 数据层需实现跨云最终一致，例如用 Debezium + Kafka 同步数据库变更，各云环境消费者各自更新本地副本
- Nginx 不管数据是否同步，它只负责把请求发过去——发出去了，但数据没对上，问题就出在后端契约或同步链路上
不复杂但容易忽略
