启用bybusyness调度算法可实现基于集群活跃连接数的智能负载均衡,需加载mod_lbmethod_bybusyness模块,配置lbmethod=bybusyness,并建议搭配健康检查提升可靠性。

用 mod_proxy_balancer 实现基于集群活跃连接数的智能分配,核心是启用 bybusyness 调度算法——它会把新请求优先发给当前活跃请求数最少的后端节点,天然适配动态负载变化,比轮询或按流量更及时、更公平。
确认并加载必要模块
Apache 2.4+ 中,bybusyness 不是 mod_proxy_balancer 自带的,而是由独立模块 mod_lbmethod_bybusyness 提供。必须显式启用:
- Ubuntu/Debian:运行
a2enmod lbmethod_bybusyness - RHEL/CentOS:在
/etc/httpd/conf.modules.d/00-proxy.conf中添加LoadModule lbmethod_bybusyness_module modules/mod_lbmethod_bybusyness.so - 验证是否生效:
httpd -M | grep bybusyness应输出lbmethod_bybusyness_module (shared)
配置 balancer 使用 bybusyness 算法
在 <proxy></proxy> 块中明确指定 lbmethod=bybusyness,无需额外参数,算法自动统计每个后端的当前活跃请求数(即已转发但尚未收到完整响应的连接):
<proxy balancer:>
BalancerMember http://192.168.1.10:8080 route=node1
BalancerMember http://192.168.1.11:8080 route=node2
ProxySet lbmethod=bybusyness
</proxy>
ProxyPass "/api/" "balancer://mycluster/api/"
ProxyPassReverse "/api/" "balancer://mycluster/api/"
注意:loadfactor 在 bybusyness 下仍有效,用于微调权重(例如某节点性能更强,可设 loadfactor=2),但最终决策仍以实时繁忙度为主。
FastAPI + Flask 混合部署最佳实践,解决路由定义、API 代理等常见问题,适用于同时运行 FastAPI API 与 Flask 前端的场景。
配合健康检查提升可靠性
bybusyness 只反映“正在处理中”的请求数,不感知节点是否宕机或卡死。建议搭配主动健康检查,避免把请求持续打向无响应节点:
- 启用
mod_proxy_hcheck(Apache 2.4.43+) - 为每个成员添加心跳配置:
BalancerMember http://192.168.1.10:8080 hcmethod=GET hcuri="/health" hcinterval=5 hcexpr="%{REQUEST_STATUS} == 200" - 未启用 hcheck 时,至少设置
timeout=5 retry=60,让被动失败机制能及时剔除异常节点
验证与观察效果
启用 mod_status 和 balancer-manager 页面,访问 /balancer-manager(需配置权限)可直观看到:
- 各
BalancerMember的 “Busy” 列数值(即当前活跃连接数) - “Ready”、“Elected” 计数,辅助判断分发是否均匀
- 状态列是否为 “OK”,确认健康检查正常工作
压测时观察 Busy 值波动,若某节点长期远高于其他节点,需检查其应用层响应延迟或线程池瓶颈,而非代理配置问题。










