最简单有效的应对硬件差异方式是在upstream块中为每台后端服务器设置weight值，需写在server行后，仅接受正整数，应反映真实吞吐或CPU能力比，并配合健康检查与slow_start等机制确保实效。
直接在 upstream 块里给每台后端服务器设 weight，是最简单也最有效的应对硬件差异的方式。它不改架构、不装模块，把 CPU 核心数、压测 QPS 或实际吞吐比，变成一行可读、可调、可验证的整数。
权重必须写在 upstream 的 server 行里
这是硬性语法要求，写错位置 Nginx 会直接报错：
- ✅ 正确：在
upstream内，紧挨 server 地址后写 ——server 192.168.1.10:8080 weight=5; - ❌ 错误：写在
location或proxy_pass附近，Nginx 提示unknown directive "weight" - ❌ 错误：绕过
upstream，直接proxy_pass http://192.168.1.10:8080，weight 完全不生效
数值要反映真实能力，别靠感觉
weight 不是百分比，也不是小数，它是相对比例，且只接受正整数：
- 新服务器吞吐 1200 QPS，旧服务器只有 300 QPS → 吞吐比 4:1 → 设
weight=4和weight=1 - 三台机器 CPU 分别为 16C、8C、4C → 粗略按核数比设
weight=4、weight=2、weight=1 - 避免用太小的数（如 1 和 2），推荐统一放大——
10:4:2比5:2:1更易对齐流量，也更利于后续微调
必须配健康检查，否则权重再准也没用
weight 只管“正常时怎么分”，不管“出问题了怎么办”。没健康机制，慢节点照样收请求：
- 每个
server行加上max_fails=3 fail_timeout=30s：连续 3 次超时或 5xx 就暂停转发，30 秒后自动试探恢复 - 故障期间，剩余健康节点会按各自 weight 归一化重分流量（比如原 5:3:2，C 下线后 A/B 实际承接比变为 5:3）
- 新节点上线建议加
slow_start=30s，让流量从零缓慢爬升，防冷启动打满
按路径或特征做分流，补足 server 级权重的不足
当一台机器跑多个服务，或接口资源消耗差异大时，单靠 server 权重不够精细：
- 用
location拆 upstream：用户中心走user_backend，订单服务走order_backend，互不抢资源 - 高并发缓存类接口（如商品详情）可单独指向一组高权重缓存节点
- 避免和
ip_hash或hash $request_uri混用——这些策略会覆盖 weight 的分配逻辑
不复杂但容易忽略：改完记得 nginx -t 验证语法，再 nginx -s reload；用日志里的 $upstream_addr 字段统计实际分发，比理论值更重要。
