bybusyness算法通过实时选择活跃连接数最少的后端节点分发请求，不感知cpu、内存或响应时间；需启用mod_proxy、mod_proxy_http、mod_proxy_balancer和mod_lbmethod_bybusyness模块，proxyset lbmethod=bybusyness必须置于块内，且依赖后端keep-alive正常工作。
用 bybusyness 算法平衡后端实时并发压力，核心是让 Apache 把新请求发给「当前活跃连接数最少」的节点——不是看 CPU、内存或响应时间，而是看它正处理几个请求。这在突发流量下比轮询更稳，但效果高度依赖配置细节和后端配合。
必须启用并验证的模块
bybusyness 不是默认开启的功能，漏掉任一模块都会导致配置失败或被忽略：
- mod_proxy 和 mod_proxy_http：反向代理基础
- mod_proxy_balancer：负载均衡框架载体
- mod_lbmethod_bybusyness：算法本体（Apache 2.4.17+ 自带，但需显式加载）
Debian/Ubuntu 执行：a2enmod lbmethod_bybusyness；RHEL/CentOS 检查 /etc/httpd/conf.modules.d/00-proxy.conf 中是否有对应 LoadModule 行。验证命令：apachectl -M | grep -E 'proxy|lbmethod'，输出中必须含 lbmethod_bybusyness_module。
正确写法：ProxySet 必须在 块内
常见错误是把 lbmethod=bybusyness 写在 BalancerMember 行尾，或放在 <virtualhost></virtualhost> 顶层——这些都无效。必须这样写：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
<proxy balancer:>
BalancerMember http://192.168.1.10:8080 timeout=5 retry=30
BalancerMember http://192.168.1.11:8080 timeout=5 retry=30
ProxySet lbmethod=bybusyness
</proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
注意：timeout=5 和 retry=30 是推荐值，避免因单次超时误判连接堆积；ProxySet 必须紧接在所有 BalancerMember 之后、 之前。
让“活跃连接数”真正可信的关键设置
bybusyness 的计数靠 Apache 内部跟踪「已发出但未收到完整响应」的连接。若后端行为不配合，这个数就失真，算法退化为轮询：
- 后端必须开启 Keep-Alive，且返回
Connection: keep-alive头；Tomcat/Jetty 要确认maxThreads设置合理，避免线程池满而 Apache 仍认为可接收请求 - 禁用粘性会话：
ProxySet stickysession=这行要注释或删除，否则用户被固定，连接数分布完全失衡 - KeepAliveTimeout 建议 ≥15 秒（Apache 和后端两端都要配），太短会导致连接频繁重建，计数不准
它不适合什么场景
bybusyness 不是万能解药：
- 不适用于长连接主导的服务（如 WebSocket、SSE），因为连接长期存在，但实际业务压力可能很低
- 后端响应时间差异极大时，它无法感知慢节点——一个节点可能只处理 1 个超慢请求，却挡住所有新流量
- Apache 2.4.37+ 已将 bybusyness 标记为废弃，官方倾向用
byrequests+ 动态权重 + 健康检查组合替代
