怎么利用Apache mod_proxy_balancer实现基于集群活跃连接数的智能负载分配-Apache-PHP中文网

Apache 2.4+ 使用 bybusyness 算法可让请求自动流向空闲节点，它基于各后端实时活跃连接数分配流量，需启用 mod_slotmem_shm 和 mod_proxy_http，lbmethod=bybusyness 必须置于块内，并为每个 BalancerMember 显式配置 timeout、keepalive=On 及 max 连接限制。

怎么利用apache mod_proxy_balancer实现基于集群活跃连接数的智能负载分配

用 bybusyness 算法替代轮询，让请求自动流向空闲节点

Apache 2.4+ 的 mod_proxy_balancer 支持 bybusyness 负载策略，它不按请求数或流量分配，而是实时统计每个后端的当前活跃连接数（即正在处理的请求），优先转发给连接数最少的节点。这对突发流量、长连接（如 WebSocket、流式 API）或响应时间差异大的服务特别有效。

关键点是：它依赖 mod_slotmem_shm 共享内存模块记录各节点的并发连接状态，且必须启用 mod_proxy_http（或其他协议模块）才能正确计数。

lbmethod=bybusyness 必须写在块内，不能放在 ProxyPass 行里
每个 BalancerMember 必须显式设置 timeout 和 keepalive=On，否则连接数统计可能失真
若后端使用 HTTP/1.1 持久连接但未正确关闭，bybusyness 可能误判“连接堆积”，建议搭配 max=50 限制单节点最大并发连接数

配置示例：带连接数限制与健康检查的 bybusyness 集群

以下配置片段可直接放入或主配置中，假设后端为两台 Tomcat：

<proxy balancer:>
    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 的实时连接数需要两个前提：

Umbrel Proxy Manager

高效管理与交互 Umbrel 代理服务，支持 Docker 容器。自动发现运行服务，将内部 Docker IP 映射为可访问的外部地址。

下载

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 匹配优先于连接数判断 —— 这个顺序容易被文档忽略，但直接影响会话一致性。