Apache 2.4+ 使用 bybusyness 算法可让请求自动流向空闲节点，它基于各后端实时活跃连接数分配流量，需启用 mod_slotmem_shm 和 mod_proxy_http，lbmethod=bybusyness 必须置于 块内，并为每个 BalancerMember 显式配置 timeout、keepalive=On 及 max 连接限制。
用 bybusyness 算法替代轮询，让请求自动流向空闲节点
Apache 2.4+ 的 mod_proxy_balancer 支持 bybusyness 负载策略，它不按请求数或流量分配，而是实时统计每个后端的当前活跃连接数（即正在处理的请求），优先转发给连接数最少的节点。这对突发流量、长连接（如 WebSocket、流式 API）或响应时间差异大的服务特别有效。
关键点是：它依赖 mod_slotmem_shm 共享内存模块记录各节点的并发连接状态，且必须启用 mod_proxy_http（或其他协议模块）才能正确计数。
-
lbmethod=bybusyness必须写在<proxy></proxy>块内，不能放在ProxyPass行里 - 每个
BalancerMember必须显式设置timeout和keepalive=On，否则连接数统计可能失真 - 若后端使用 HTTP/1.1 持久连接但未正确关闭，
bybusyness可能误判“连接堆积”，建议搭配max=50限制单节点最大并发连接数
配置示例：带连接数限制与健康检查的 bybusyness 集群
以下配置片段可直接放入 <virtualhost></virtualhost> 或主配置中，假设后端为两台 Tomcat：
<Proxy balancer://myapp>
BalancerMember http://192.168.1.10:8080 \
route=app1 \
timeout=5 \
keepalive=On \
max=40 \
hcmethod=GET \
hcinterval=15 \
hcuri="/health" \
hcexpr="%{REQUEST_STATUS} == 200"
BalancerMember http://192.168.1.11:8080 \
route=app2 \
timeout=5 \
keepalive=On \
max=40 \
hcmethod=GET \
hcinterval=15 \
hcuri="/health" \
hcexpr="%{REQUEST_STATUS} == 200"
ProxySet lbmethod=bybusyness
</Proxy>
ProxyPass "/api/" "balancer://myapp/"
ProxyPassReverse "/api/" "balancer://myapp/"
注意：hcmethod 和 hcexpr 是 Apache 2.4.43+ 才支持的主动健康检查语法；若版本较低，需改用被动检测（failonstatus=500,503 + retry=60）。
为什么 /balancer-manager 页面看不到“Busy”列？
这是最常被忽略的兼容性问题：/balancer-manager 默认只显示 byrequests 或 bytraffic 下的权重和请求计数，bybusyness 的实时连接数需要两个前提：
-
mod_status必须启用（a2enmod status或手动加载） -
mod_slotmem_shm必须启用（否则无共享内存存储连接状态，bybusyness退化为随机分发） - 访问
/balancer-manager的客户端 IP 必须在Require ip白名单中，否则页面加载不全，Busy 列直接消失
验证方式：curl -I http://localhost/balancer-manager | grep "200 OK" 成功后，再检查 HTML 源码里是否有 Busy 字样 —— 没有就说明 mod_slotmem_shm 未生效或路径权限不对（Apache 进程需对 /var/run/apache2/ 或对应 shm 目录有写权限）。
bybusyness 在高并发下容易卡住的几个实际表现
不是算法本身有问题，而是配置或环境没对齐：
- 后端返回
Connection: close但 Apache 仍尝试复用连接 → 加setenv force-response-1.0强制降级 HTTP/1.0 - 后端超时设为 30s，而 Apache 的
timeout=5导致连接提前中断，bybusyness统计频繁抖动 → 两端 timeout 应基本一致 - 启用了
SSLProxyVerify但证书链不全，握手失败后连接不释放 → 临时禁用验证测试，确认是否为 TLS 层阻塞
真实生产环境中，bybusyness 很少单独使用；它通常和 stickysession 配合（尤其 Java Web 应用 session 未共享时），此时 route 匹配优先于连接数判断 —— 这个顺序容易被文档忽略，但直接影响会话一致性。
