mod_lbmethod_bybusyness是Apache的负载均衡模块，仅按后端当前代理连接数分发请求，并非真实繁忙度；它实现“连接数最少优先”，不感知CPU、内存或响应时间，适用于短连接API服务。
mod_lbmethod_bybusyness 是什么，它真能按繁忙度分发请求？
mod_lbmethod_bybusyness 是 Apache HTTP Server 的一个负载均衡调度模块，但它**不感知后端应用的实际 CPU、内存或响应时间**。它只统计每个后端 ProxyPass 节点当前“正在处理的请求数”（即已建立连接但尚未关闭的代理请求），并优先将新请求分发给该数值最小的节点。这本质上是“连接数最少优先”，不是“繁忙度最低优先”——如果某个后端处理慢但连接很快释放（比如短连接 + 高并发），它可能被持续打满；反之，长连接多的节点反而被冷落。
所以别指望它自动适配业务层繁忙指标。它的价值在于：比轮询更适应突发流量下的连接堆积，且无需额外监控组件。
启用 mod_lbmethod_bybusyness 的最小必要配置
确保模块已加载（通常 Apache 2.4.17+ 自带）：
LoadModule lbmethod_bybusyness_module modules/mod_lbmethod_bybusyness.so
然后在 bybusyness：
<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"
-
loadfactor仍有效，用于加权（比如旧机器设为loadfactor=2表示承担两倍连接数） - 必须用
ProxySet lbmethod=bybusyness，不能只靠lbmethod=bybusyness放在BalancerMember行里 - Apache 默认不启用任何
lbmethod_*模块，漏掉LoadModule会导致启动报错：Invalid command 'BalancerMember', perhaps misspelled or defined by a module not included in the server configuration
为什么请求没按预期分发？常见陷阱
现象：两个后端节点连接数明显不均，bybusyness 像没生效。
- 后端未正确设置
KeepAlive或Connection: close头 —— 如果后端主动断连太快，Apache 无法准确计数“忙连接”，会退化成近似轮询 - 启用了
ProxySet stickysession=...但 session cookie 无效，导致大量请求被绑定到单个节点，掩盖了调度逻辑 - 使用了
ProxyPass /app !排除规则却写在balancer://定义之前，导致部分路径根本没走负载均衡 - Apache 进程模型影响：prefork MPM 下每个子进程独立维护连接计数，而 worker/event MPM 共享计数更准；若用 prefork，需确保
MaxRequestWorkers足够高，否则子进程频繁重启重置计数
和 byrequests / bytraffic 对比，什么时候该选 bybusyness？
三者核心差异在“谁决定下一个请求发给谁”：
-
byrequests：纯计数，简单但无视响应快慢；适合后端性能高度一致的场景 -
bytraffic：按已转发字节数加权，适合大文件下载类服务；但小请求密集时几乎等同于byrequests -
bybusyness：唯一考虑“此刻是否空闲”的方法，对突发短连接敏感；适合后端响应时间波动大、且连接生命周期较短的 API 服务
注意：bybusyness 的计数粒度是“Apache 到后端的代理连接”，不是客户端到 Apache 的连接。如果你用 HTTPS 反向代理，且后端也用 HTTPS，那 TLS 握手开销、证书验证延迟等都算在 Apache 连接生命周期内，会放大计数偏差。
真正难的是让后端连接行为可预测——比如强制设置 Keep-Alive: timeout=5, max=100，比调模块参数重要得多。
