bybusyness算法严格依据后端当前活跃代理连接数调度，连接越少越优先，不感知CPU、内存或响应时间；需加载三个模块、用ProxySet显式设置lbmethod=bybusyness，并依赖后端KeepAlive正常工作。
Apache 的 bybusyness 算法不是按“繁忙度”字面意义调度，而是严格依据每个后端当前**活跃代理连接数**（即已建立、尚未关闭的 HTTP 连接）来分发新请求——连接越少，越优先。它不看 CPU、内存、响应时间或业务耗时，只做一件事：把请求交给此刻“手头活最少”的节点。
确认模块已启用且可用
该模块自 Apache 2.4.17 起内置，但默认不加载。缺任何一项都会导致启动失败，报错如 Invalid command 'BalancerMember'。
- 检查配置文件（如
/etc/httpd/conf.modules.d/00-proxy.conf或/etc/apache2/mods-enabled/proxy.load）中是否包含以下三行：
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule lbmethod_bybusyness_module modules/mod_lbmethod_bybusyness.so
- 运行验证命令：
apachectl -M | grep -E 'proxy|lbmethod'，输出中必须同时出现proxy_balancer_module和lbmethod_bybusyness_module。
正确声明调度算法
必须在 ProxySet lbmethod=bybusyness 显式设置——写在 BalancerMember 行末尾的 lbmethod=bybusyness 会被忽略。
最小有效配置示例：
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
BalancerMember http://192.168.1.10:8080 loadfactor=1
BalancerMember http://192.168.1.11:8080 loadfactor=1
ProxySet lbmethod=bybusyness
ProxyPass "/app" "balancer://mycluster/app"
ProxyPassReverse "/app" "balancer://mycluster/app"
-
loadfactor仍有效，可用于加权（例如旧服务器设为loadfactor=2，表示允许承载约两倍于其他节点的活跃连接） - 若需查看实时连接分布，可启用
balancer-manager页面，便于观察各节点当前 busy 值
确保后端配合 KeepAlive
bybusyness 的准确性高度依赖后端对连接的管理。如果后端频繁主动断连（如返回 Connection: close），Apache 就无法稳定维持和统计“忙连接”，算法会退化为近似轮询。
- 后端应开启 HTTP KeepAlive，并设置合理超时（如
KeepAliveTimeout 5） - 避免在应用层强制关闭长连接；尤其注意反向代理链路中中间网关（如某些 WAF 或 LB）是否静默终结连接
- 使用
curl -v或抓包确认响应头含Connection: keep-alive
避开常见失效场景
即使配置无误，实际流量也可能未按预期分发，原因常不在算法本身，而在周边约束：
- 启用了
stickysession但 cookie 无效或被拦截，大量请求被绑定到单个节点，掩盖了 bybusyness 的调度效果 -
ProxyPass排除规则（如ProxyPass /static !）写在 - 使用 prefork MPM 时，每个子进程独立维护连接计数，不如 worker/event MPM 下的共享计数准确——高并发下建议切换至 event 模式
