负载均衡权重的本质，是让服务器按你设定的比例分担流量，它不是简单的数字调大调小，而是流量分配策略的核心杠杆。
权重这个参数，在负载均衡里扮演的角色有点像交通路口的信号灯配时，信号灯分配给主干道的时间长，车流通过量自然就大，服务器权重也是同理，你给某台后端服务器配了更高的权重，它就能承接更多请求，但很多人只把权重当成一个“多分点流量”的开关，忽略了它背后的算法逻辑、场景适配和动态调整策略，这篇文章会把权重从配置到优化、从算法到实战讲透。
权重到底在分配什么：从流量比例到资源效率
权重直接影响的是请求分配比例，但这个比例的呈现方式，取决于你用的是哪种负载均衡算法，搞清楚这一点,才能理解为什么有时候权重设置和预期效果对不上。
加权轮询：最直观的“按劳分配”
加权轮询是应用最广的算法，它的逻辑很朴素：后端有三台服务器，权重分别是 5、3、2，那么每 10 个新请求里，大约有 5 个落到第一台，3 个落到第二台，2 个落到第三台，这里有个细节容易忽略：轮询的顺序是平滑的，nginx 的实现里，加权轮询不是“先连续给 A 发 5 个，再给 B 发 3 个”，而是通过算法把请求打散,避免某台机器短时间被突增流量打满。
加权最少连接：让权重“动态化”
如果后端服务器的处理能力差异较大，或者请求耗时很不均匀，单纯靠加权轮询会出问题，比如一台老机器权重是 2，但它的长连接请求每个要处理 5 秒；另一台新机器权重是 3，但请求都是毫秒级响应，按轮询分，老机器可能被压垮，加权最少连接算法会动态参考当前活跃连接数，再结合权重做计算，权重这时更像一个“修正系数”,而不是固定比例。
什么场景下权重会失效
你可能会遇到这种情况：权重明明调大了，但流量没变化,常见原因有三个：
- 客户端开启了 keep-alive 长连接，连接一旦建立，后续请求都走同一个连接，负载均衡器没法重新分配
- 负载均衡器工作在四层（传输层），只按连接分发，不感知请求级别的内容
- 权重值设置过小，比如在 1-2 之间调整，对流量分布的扰动不明显
nginx负载均衡权重配置的实操细节
nginx 的权重配置是入门级操作，但很多人在细节上踩坑，最典型的是
权重和服务器地址的绑定关系。
upstream backend {
server 192.168.1.10 weight=5;
server 192.168.1.11 weight=3;
server 192.168.1.12 weight=2;
}
这段配置的含义是：在一段轮询周期内，三台服务器按 5:3:2 的比例接收请求，但这里有个容易被忽略的点：weight 参数只对 nginx 自己的负载均衡算法生效，upstream 里配置了 keepalive 指令,连接复用会直接影响权重效果。
调整权重后需要 reload 吗
需要，nginx 的 upstream 配置变更必须执行 nginx -s reload 才能生效，reload 过程是平滑的，不会中断现有连接，但新连接会使用新权重，如果权重调整后没生效，排查顺序是：先确认配置语法正确（nginx -t），再确认 reload 确实执行了，最后检查是否有多个 upstream 块或者配置被 include 到了其他位置。
四层负载均衡的权重设置差异
LVS 或者 F5 这类四层设备的权重配置，作用在连接级别，每一条 TCP 连接建立时，负载均衡器根据权重选择一个后端，这种模式下，连接持有时长比请求数更重要，比如权重分配了 50% 的连接，但其中一方是数据库长连接池，另一方是短连接 HTTP 请求,实际流量差异会非常大。
负载均衡权重算法对比：轮询、最少连接与一致性哈希
把三种主流带权算法放在一起看,差异会更清楚。
| 算法类型 | 权重作用方式 | 适合场景 | 容易踩的坑 |
|---|---|---|---|
| 加权轮询 | 按固定比例分配请求 | 请求处理时长相近，服务器配置均匀 | 长连接场景下权重失真 |
| 加权最少连接 | 权重叠加在连接数之上 | 请求耗时差异大，需要动态平衡 | 连接数不能反映真实 CPU 负载 |
| 加权一致性哈希 | 权重影响虚拟节点数量 | 需要会话保持，缓存命中优先 | 权重调整会引发大规模哈希重映射 |
一致性哈希里的权重，逻辑又不一样，它把每个服务器映射成若干个虚拟节点，权重越大，虚拟节点越多，被哈希命中的概率就越高，这种模式的优点是会话保持，同一个客户端 IP 或请求特征会固定落在同一台服务器上，缺点也明显：调整权重时，虚拟节点的增减会导致相当一部分请求被重新映射,可能引起缓存雪崩。
动态权重：从“静态配置”到“实时调整”
传统负载均衡的权重是静态的，改完要 reload，现在的云原生环境里，动态权重越来越常见，Spring Cloud LoadBalancer 支持基于响应时间的权重计算，响应越快权重越高，这种机制的好处是自适应，但要注意权重振荡问题：如果某台机器响应变快，权重升高，更多流量打过去，响应又变慢，权重又降下来,形成震荡。
负载均衡权重怎么设置才能贴合真实业务场景
权重不是拍脑袋定的，需要结合服务器硬件、业务特性、流量模型来推算,这里给出一套可执行的设置步骤。
第一步：评估服务器处理能力的差异
看三个指标：CPU 核数、内存大小、磁盘类型，一台 8 核 16G 的机器和一台 4 核 8G 的机器，权重比直接设为 2:1 是合理的起步值，但要注意，如果业务是 IO 密集型，磁盘性能的差异比 CPU 更关键,权重比要按磁盘吞吐能力来定。
第二步：观察业务请求的耗时分布
用 APM 工具或者访问日志统计每个接口的 P95 耗时，如果发现 80% 的请求都集中在几个“重接口”上，这些请求对 CPU 的消耗远高于平均值，那么单纯按服务器配置设置权重是不够的，行业共识认为，权重设置应该参考 CPU 密集型请求占比，而不是只看总请求数。
第三步：小步调整，观察流量曲线
权重调整切忌一步到位，比如你要把一台服务器的权重从 5 调到 10，不如先调到 7，观察 10-15 分钟，看 CPU 使用率、响应时间、错误率的变化趋势，再决定是否继续上调，这个过程在压测环境里提前演练一遍,比直接上生产要稳妥得多。
权重和健康检查的联动：一台服务器宕机后会发生什么
权重配置得再好，如果健康检查没跟上，也会出乱子，设想一个场景：A 服务器权重是 10，B 和 C 权重都是 1，A 突然宕机,负载均衡器会怎么做？
- 如果配置了主动健康检查，负载均衡器会在下一个检查周期发现 A 不可用，将其摘除，流量全部落到 B 和 C 上
- 如果没配置健康检查，请求依然会按权重转发到 A，导致大量连接超时
- 如果配置了被动健康检查（nginx 的 max_fails 和 fail_timeout），连续失败达到阈值后，A 会被临时标记为不可用
这里有一个关键点：
权重值不会影响健康检查的判定结果，A 的权重再高，健康检查失败后照样被摘除；A 恢复后，权重会原样生效,不会因为之前宕机而受到惩罚。
故障转移时的权重“雪崩”问题
当一台高权重服务器下线，它的流量会瞬间分摊到其他低权重服务器上，如果剩余服务器本来就在高负载运行，这个突增流量很可能引发连锁故障，业内专家指出，这种场景下应该给负载均衡器配置最大连接数限制或者过载保护,而不是依赖权重本身的调节。
关于负载均衡权重设置的常见问题解答
负载均衡权重配置后轮询不均，可能是什么原因
首先检查是不是有长连接复用，客户端连接池如果默认复用连接，会导致请求始终走同一台后端，权重分配完全失效，其次看负载均衡器的工作模式，四层 LB 按连接分发，如果连接数量少但每个连接内请求多，权重比例会失真，最后确认权重值本身是否设置了过小的差值，比如权重 1 和 2 的区别,在并发量不足的情况下可能看不出明显差异。
权重值和服务器实际负载能力必须一致吗
不需要完全一致，但偏差过大会出问题，权重本质上是一个“期望比例”，不是“硬性限制”，如果某台服务器权重设置得高于它的实际处理能力，它会被打满，响应变慢，甚至拖累整个集群，反过来，权重设置过低，服务器资源闲置，又浪费了成本，建议权重值参考服务器在多长时间内能完成多少有效请求来估算，而不是直接按 CPU 核数换算。
调整权重时，如何避免影响正在进行的业务
大多数负载均衡器支持平滑调整权重，不需要重启服务，nginx 的 upstream 支持在 reload 时平滑更新，AWS 的 ALB 支持直接修改 target group 的权重并自动生效，调整过程中，建议将单次调整幅度控制在原有权重的 20% 以内，观察稳定后再继续调整，如果业务允许，尽量在低峰期操作,减少调整过程中因流量重新分布带来的不确定性。
写在最后
权重是负载均衡配置里最直观但最容易被误用的参数，它解决的是“流量按什么比例分配”的问题，但比例背后的算法逻辑、健康检查联动、业务场景适配，才是真正决定权重能否发挥效用的关键，把权重当成一个持续优化的动态指标，配合监控数据和实际流量反馈来调整,比一次设置到位更靠谱。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/574882.html
