nginx加权轮询通过upstream中server的weight参数实现，按相对权重比例分发请求，需搭配max_fails和fail_timeout做健康检查，并reload生效；weight默认1、最小1、不支持0，避免过高权重与忽略后端能力变化。
直接在 upstream 块里给每台后端服务器加 weight 参数就行，Nginx 会按权重比例分发请求，算力强的机器多扛活，算力弱的少分担——不需要改代码、不依赖外部模块，原生支持。
加权轮询的核心配置写法
weight 值是相对比例，不是绝对数值。比如三台服务器：一台 16 核（高性能），两台 4 核（普通），可设 weight=4、2、2，请求分配比就是 50% / 25% / 25%。
- 配置示例（放在
http{}块内）：
upstream backend {
server 192.168.1.10:8080 weight=4;
server 192.168.1.11:8080 weight=2;
server 192.168.1.12:8080 weight=2;
}
- weight 默认是 1，不写就等同于
weight=1；最小值为 1，不能设 0 或小数（Nginx 1.10+ 支持小数，但慎用，实测稳定性略低）； - 所有 weight 值加起来叫“总权重”，Nginx 按每个 server 的 weight 占总权重的比例来调度；
- weight 只在加权轮询模式下生效，和
ip_hash或least_conn冲突，不能混用。
搭配健康检查，避免把流量压到故障机上
光靠 weight 不够，万一某台高权重机器挂了，Nginx 还会继续往它身上发请求。得加上自动故障隔离机制：
- 在每行
server后追加max_fails=3 fail_timeout=30s，表示连续失败 3 次后，30 秒内不再转发请求过去； - 推荐完整写法：
server 192.168.1.10:8080 weight=4 max_fails=3 fail_timeout=30s; - 注意：Nginx 默认只做 TCP 层探活，如需 HTTP 级健康检查（比如检测返回码是否为 200），要配合
nginx-plus或用第三方模块（如nginx_upstream_check_module）。
验证请求是否按权重分配
别只看配置，一定要实测。两种轻量方式：
- 用
curl快速轮询 20 次，配合后端日志观察分布：for i in {1..20}; do curl -s http://your-nginx-ip/health; done - 用
ab（Apache Bench）模拟并发，更贴近真实场景：ab -n 600 -c 100 http://your-nginx-ip/，再统计各后端 access.log 中的请求数； - 预期结果：若 weight 是 4:2:2，600 次请求大致应落在 300 / 150 / 150 左右（允许少量偏差，因 Nginx 内部使用平滑加权轮询算法，非严格周期循环）。
几个容易踩的坑
- 权重设太高反而不好：单台 weight=10 而其他都是 1，会导致它承担近 90% 流量，一旦出问题影响面太大，建议最大 weight ≤ 5，且总权重控制在 10–20 区间较稳妥；
- 别忽略后端处理能力变化：比如某台机器升级了 CPU，记得同步调高它的 weight，否则负载会失衡；
-
reload 配置才生效：改完
nginx.conf后执行nginx -t && nginx -s reload，不要用 restart，避免连接中断； -
weight 不解决长连接或状态粘滞问题：如果业务有登录态、文件上传中等场景，单纯加权轮询可能造成 session 丢失，这时得考虑
ip_hash或后端共享 session。
