mod_lbmethod_bybusyness是连接数最少优先算法，仅依据后端当前处理中的连接数分配请求，不感知CPU、内存或响应时间；需显式加载模块并用ProxySet lbmethod=bybusyness配置，依赖后端KeepAlive正常工作。
mod_lbmethod_bybusyness不感知 CPU、内存或响应时间，只看每个后端当前“正在处理的请求数”（即已建立但未关闭的代理连接数）。它本质是「连接数最少优先」，不是业务层意义上的“最空闲”。用对了能缓解突发流量堆积；用错了会发现负载反而更不均。
确认模块已加载且可用
Apache 2.4.17+ 自带 mod_lbmethod_bybusyness，但默认不启用。漏掉这步会导致启动失败：
Invalid command 'BalancerMember', perhaps misspelled or defined by a module not included in the server configuration
检查并确保以下三行都在主配置中（如 /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'，输出里必须含 lbmethod_bybusyness_module 和 proxy_balancer_module。
正确声明 lbmethod=bybusyness
必须用 ProxySet lbmethod=bybusyness 显式设置在 BalancerMember 行末尾——后者会被忽略。
最小有效配置示例：
<proxy>
BalancerMember http://192.168.1.10:8080 loadfactor=1
BalancerMember http://192.168.1.11:8080 loadfactor=1
ProxySet lbmethod=bybusyness
</proxy>
ProxyPass "/app" "balancer://mycluster/app"
ProxyPassReverse "/app" "balancer://mycluster/app"
注意点：
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
loadfactor仍生效，可用于加权（比如老机器设loadfactor=2） - 若用了
stickysession但 cookie 解析失败（如 route 值不匹配），请求会 fallback 到bybusyness，但你可能根本意识不到——先关掉 sticky 测试再开 - 路径排除规则（如
ProxyPass /static !）必须放在ProxyPass指向 balancer 之前，否则部分请求压根不进均衡逻辑
后端行为直接影响 bybusyness 效果
bybusyness 的计数完全依赖 Apache 能否准确判断“连接是否还在忙”。如果后端频繁主动断连，计数就失真，算法退化为轮询。
关键控制点：
- 后端必须支持并开启
KeepAlive On，且KeepAliveTimeout不宜过短（建议 ≥15s） - 后端响应头不能带
Connection: close（除非真要强制短连接） - 避免后端在处理完成前就提前
flush并关闭连接（尤其 Node.js/Python WSGI 场景） - prefork MPM 下各子进程独立计数，容易抖动；event 或 worker MPM 更准——若用 prefork，请确保
MaxRequestWorkers足够高，减少子进程重启重置计数
为什么请求没按连接数分发？排查方向
现象：两个节点连接数持续相差 2 倍以上，balancer-manager 页面显示活跃请求数却很接近。
重点查这几处：
- 是否启用了
ProxySet stickysession=JSESSIONID，但后端没返回该 cookie？此时所有请求都 fallback 到第一个BalancerMember（因为 route 匹配失败，默认选首个） - 后端健康状态异常：某个节点被标记为
down（看balancer-manager状态列），所有流量实际只打到剩下一个 - 防火墙或网络设备干扰了 Apache 到后端的连接复用（如中间设备强制 kill 长连接）
- 日志里是否有大量
proxy: error reading status line from remote server？说明连接被后端非正常中断，bybusyness计数无法维持
真正起作用的永远不是“算法名字”，而是 Apache 实际看到的连接生命周期——这点比调参重要得多。
