apache实现最小连接数负载均衡需启用mod_proxy_balancer及mod_lbmethod_bybusyness模块,配置lbmethod=bybusyness算法,并配合健康检查、keep-alive连接复用与合理超时重试,确保实时按后端活跃连接数智能分发请求。

Apache 实现基于最小连接数(Least Connections)的负载均衡,需依赖 mod_proxy_balancer 模块,并在启用 lbmethod=bybusyness 时生效。该算法自 Apache 2.4.33 起正式支持,不是默认启用项,且与旧版 lbmethod=byrequests(按请求数轮询)有本质区别。
✅ 确认模块已加载并启用
确保以下模块在 httpd.conf 或 mods-enabled/ 中启用:
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 LoadModule slotmem_shm_module modules/mod_slotmem_shm.so
注意:
mod_slotmem_shm是mod_proxy_balancer的依赖模块,缺失会导致 balancer 启动失败。
✅ 配置最小连接数调度策略
在 <virtualhost></virtualhost> 或全局配置中定义 ProxyPass + Balancer,关键点如下:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
<proxy>
BalancerMember http://192.168.1.10:8080 route=node1 loadfactor=1
BalancerMember http://192.168.1.11:8080 route=node2 loadfactor=1
ProxySet lbmethod=bybusyness
</proxy>
ProxyPass "/api/" "balancer://mycluster/"
ProxyPassReverse "/api/" "balancer://mycluster/"
-
lbmethod=bybusyness是 Apache 中对应 “least connections” 的官方实现名称(语义等价,但命名不同) -
loadfactor可设为不同值实现加权最小连接(即加权 least connections),例如loadfactor=2表示该节点可承担约两倍于loadfactor=1节点的连接压力 - 不支持
stickysession与bybusyness混用(会降级为byrequests);如需会话保持,应改用lbmethod=bytraffic+route或上层应用级粘性
✅ 强化连接感知能力(避免“假低连接”)
最小连接数调度效果高度依赖后端是否复用连接。若后端使用短连接,Apache 统计的“当前连接数”将严重失真:
- 后端服务必须开启 HTTP Keep-Alive(如 Tomcat 设置
keepAliveTimeout > 0,Spring Boot 默认启用) - Apache 侧无需额外配置 keepalive(
mod_proxy默认复用连接),但建议显式启用长连接透传:
ProxyRequests Off ProxyPreserveHost On # 确保 Connection 头不被篡改,让后端正确复用连接 RequestHeader unset Connection
✅ 健康检查与故障隔离(防止调度到假活节点)
bybusyness 只看连接数,不判断节点是否响应慢或卡死。必须叠加健康检查:
<proxy>
BalancerMember http://192.168.1.10:8080 route=node1 status=+H
BalancerMember http://192.168.1.11:8080 route=node2 status=+H
ProxySet lbmethod=bybusyness
ProxySet timeout=5 retry=30
</proxy>
-
status=+H启用被动健康检查(自动标记连续失败的节点为hot-standby) - 更推荐主动健康检查(需启用
mod_proxy_hcheck):
BalancerMember http://192.168.1.10:8080 hcmethod=OPTIONS hcuri=/health hcinterval=10 hcpasses=2 hcfails=3
hcmethod=OPTIONS是轻量探测方式,避免触发业务逻辑;hcuri应指向后端真实健康检查端点(如/actuator/health)
✅ 验证调度效果
- 访问
http://your-apache-server/balancer-manager(需授权访问)查看各成员的Busy列数值,压测时应趋于接近 - 日志中开启
%{BALANCER_WORKER_ROUTE}e和%{BALANCER_SESSION_STICKY}e变量,确认请求实际分发路径 - 结合后端监控,比对
active connections与p95 response time:若某节点连接数低但延迟高,说明存在 I/O 阻塞或 GC 卡顿,需排查而非归因于调度算法
不复杂但容易忽略









