weight参数是最有效轻量的负载均衡解法，需在upstream块中server行后配置正整数比例值，并配合max_fails、fail_timeout、slow_start等健康机制及location/hash/least_time实现细粒度分流。
直接用 weight 参数是最有效、最轻量的解法。它不依赖额外模块，也不改变架构，把硬件或部署差异转化为可读、可调、可验证的整数比例。
权重必须写在 upstream 的 server 行里
只能出现在 upstream 块中，紧跟在 server 地址之后：
- ✅ 正确：
server 192.168.1.10:8080 weight=5; - ❌ 错误：写在
location或proxy_pass附近，Nginx 会报unknown directive "weight" - ❌ 错误：绕过 upstream 直接 proxy_pass 到 IP，weight 完全失效
数值要反映真实能力，别靠猜
weight 不是百分比，而是相对比例。设得准，才能避免“新机闲着、老机打满”：
- 以最强节点为基准（比如设
weight=10），其余按实测 QPS 或 CPU 核心数折算 - 旧机性能约为新机 40%，就设
weight=4，不是weight=0.4（只接受正整数） - 避免用太小的数（如 1 和 2），推荐统一放大 10 倍——
10:4:2比5:2:1更易对齐实际流量
权重不是万能钥匙，得配健康机制
weight 只管“正常时怎么分”，不管“出问题了怎么办”。没健康检查，慢节点照样收请求：
- 加
max_fails=2 fail_timeout=30s：连续两次超时或拒绝连接，就暂停转发 - 故障期间，剩余健康节点会按各自 weight 重新归一化分担流量（例如原 5:3:2，C 下线后 A/B 变成 5:3）
- 新节点上线可用
slow_start=30s，让流量从 0 开始缓慢爬升，防冷启动冲击
按路径或特征做更细粒度分流
当同一台机器跑多个应用，或不同接口资源消耗差异大时，单靠 server 级 weight 不够：
- 用
location拆 upstream：用户中心走user_backend，订单服务走order_backend，互不抢资源 - 缓存类接口（如商品详情）用
hash $request_uri consistent;，相同 URL 总落同一台，提升本地缓存命中率 - 耗时波动大的接口（如报表导出）可启用
least_time header;（需编译模块），优先选响应快的节点
