mod_lbmethod_bybusyness是连接数最少优先算法，仅依据后端当前处理中的连接数分配请求，不感知cpu、内存或响应时间；需显式加载模块并用proxyset lbmethod=bybusyness配置，依赖后端keepalive正常工作。
mod_lbmethod_bybusyness 并不能真正按“节点繁忙度”（如 CPU、内存、响应时间）调度，它只按每个后端当前正在处理的连接数分发请求——也就是“连接数最少优先”。这个逻辑简单直接，但容易被名字误导。用对了能缓解突发流量下的堆积；理解偏差则会导致负载不均。
它到底在忙什么？
该模块完全不采集后端的系统指标或业务指标。它只依赖 Apache 自身维护的代理连接状态：一个请求从 Apache 转发给后端、到收到完整响应并关闭连接之间，算作一个“活跃连接”。连接数越低，越可能被选中。
- 适合短连接、高并发的 API 服务，比如 REST 接口，因为连接生命周期短，计数反映较实时的负载压力
- 不适合长连接场景（如 WebSocket、SSE），连接长期挂起会虚高计数，导致节点被“误判为忙”而被跳过
- 如果后端返回 Connection: close 或未开启 KeepAlive，Apache 很难准确维持连接计数，算法可能退化为近似轮询
必须完成的三步启用
缺一不可，否则启动失败或调度失效：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 确保三个模块已加载：mod_proxy、mod_proxy_balancer、mod_lbmethod_bybusyness。检查命令：
apachectl -M | grep -E 'proxy|lbmethod'，输出中需含lbmethod_bybusyness_module - 在
<proxy></proxy>块内显式设置：ProxySet lbmethod=bybusyness。写在 BalancerMember 行末尾无效 - 启用 mod_status（通常已默认启用）。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 "/api" "balancer://mycluster/api"
ProxyPassReverse "/api" "balancer://mycluster/api"
- loadfactor 不影响 bybusyness 的决策逻辑，它仅在多个节点连接数相同时起作用（此时回退到类似 byrequests 的权重轮询）
- 若使用 sticky session（如
ProxySet stickysession=ROUTEID），务必确保后端正确注入ROUTEIDcookie，否则大量请求被绑定，掩盖调度效果 - 避免把
ProxyPass /app !这类排除规则写在 balancer 定义之前，否则匹配路径根本不会进入负载均衡流程
怎么验证它真的在工作？
访问 /balancer-manager（需已配置并授权），查看各节点的 “Busy” 列数值。真实生效时，新请求应持续流向 Busy 值更低的节点。若数值长期不变、或两节点差异极大却无变化，大概率是后端连接管理异常（如强制断连太快）或 MPM 模型不匹配（prefork 下各子进程独立计数，event/workers 才共享）。
