weight参数仅在balancer://协议的中设置才生效,默认值为1,需配合lbmethod=byrequests等算法使用,避免小数或过大值,并排除sticky session和retry机制干扰。

Apache mod_proxy_balancer 中的 weight 参数怎么设才生效
权重设置只在启用 mod_proxy_balancer 且使用 balancer:// 协议时起作用,直接写在 ProxyPass 后面的服务器地址上是无效的。必须先定义 <balancermember></balancermember>,再通过 loadfactor(旧版)或更推荐的 weight(2.4.7+)显式指定。
常见错误是把权重写成 ProxyPass / balancer://mycluster/ http://10.0.1.10:8080 weight=3 —— 这种写法 Apache 会忽略 weight 并报 Invalid ProxyPass parameter 错误。
- 正确做法:用
<proxy></proxy>块包裹多个BalancerMember -
weight默认为 1,值越大分到的请求越多,但不是严格比例(受调度算法、健康检查、sticky session 等影响) - 若某节点加了
status=+H(禁用),即使 weight 很高也不会收流量
为什么设置了 weight=5 和 weight=1,实际流量却接近 1:1
默认调度算法是 byrequests,理论上应按权重比例分发;但实际偏离严重,通常是因为启用了 sticky 或后端服务返回了 Set-Cookie: JSESSIONID 导致会话粘滞,所有同会话请求被固定到同一节点,掩盖了权重效果。
另一个常见原因是没关掉 retry 时间——某台服务器短暂超时后被标记为“临时失效”,后续几分钟内不再转发请求,造成权重失真。
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 确认是否启用 sticky:检查
ProxySet stickysession=JSESSIONID或类似配置,临时注释掉测试 - 查看实时分配情况:访问
/balancer-manager页面(需授权),观察 “Current Load” 列是否随请求增长而变化 - 调低
retry=10(单位秒)甚至设为retry=0(慎用,可能放大故障影响)
weight 和 lbmethod 的关系必须理清
lbmethod 决定如何解读 weight。比如 byrequests(默认)按请求数累加权重计数;bytraffic 按响应字节数加权;bybusyness 则完全忽略 weight,只看当前活跃连接数。
如果你希望“每 5 个请求里 4 个去 A,1 个去 B”,就必须用 byrequests,且确保 weight 设置为整数倍(如 A:4, B:1),不能写成 A:100, B:25 —— 虽然数学等价,但 Apache 内部用整型计数器,过大的 weight 值可能导致溢出或精度丢失。
- 显式声明算法:
ProxySet lbmethod=byrequests - 避免小数 weight:
weight=0.8会被截断为 0,该节点彻底不收流量 -
bytraffic在文件下载类服务中更公平,但对 API 接口意义不大
配置示例与验证要点
以下是最小可运行配置片段,注意路径和模块加载顺序:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
<proxy>
BalancerMember http://10.0.1.10:8080 weight=4
BalancerMember http://10.0.1.11:8080 weight=1
ProxySet lbmethod=byrequests
</proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
验证前务必重启 Apache,并用 curl -I http://your-proxy/ 多次发起请求,同时打开 /balancer-manager 实时观察各节点 “Requests” 计数增长是否符合预期比例。真实环境里还要考虑后端响应时间差异——快节点容易更快“消化”完自己的权重份额,导致短时间内的实际分布抖动较大。










