apache不支持加权最少连接算法，bybusyness仅按活跃连接数调度且忽略loadfactor；需用bytraffic替代或改用haproxy/nginx实现原生支持。
Apache mod_proxy_balancer 本身不直接提供“基于活跃连接数”的实时动态压制（如自动限流、主动拒绝新请求），但它支持 bybusyness 调度算法——这是最接近你需求的原生机制：它会将新请求优先分发给当前活跃请求数（即未完成响应的并发连接）最少的后端节点，从而实现**隐式的、被动的负载压制效果**。
启用 bybusyness 并配置关键参数
该算法依赖 Apache 对每个后端连接的“忙状态”统计（基于正在处理的请求计数），需配合以下设置才能真正生效：
- 在
<proxy></proxy>块中显式指定：ProxySet lbmethod=bybusyness - 为每个
BalancerMember设置合理的timeout和retry，确保连接超时能及时释放忙计数：timeout=5 retry=60 - 启用
max（最大并发连接数）可进一步约束单节点承载能力：BalancerMember http://node1:8080 max=20。当该节点活跃连接达 20，bybusyness将自动跳过它，等同于“压制”
配合健康检查提升压制准确性
仅靠 bybusyness 无法感知后端是否已过载（比如 CPU 100% 但 HTTP 连接仍能建立）。建议叠加主动健康检查：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 使用
mod_proxy_hcheck（Apache 2.4.43+）定期探测后端真实负载，例如调用自定义 /health 接口返回含 CPU/队列长度的 JSON - 通过
hcexpr表达式判断是否过载：hcexpr="%{REQUEST_STATUS} == 200 && %{HC_RES_BODY} =~ /\"load\":([0-9]+)/ && $1 ，满足条件才标记为 healthy - 当节点被
hcheck标记为 unhealthy，它会立即从调度池中摘除，相当于强压制
路径级或条件式压制（需 Rewrite 配合）
若需对特定路径（如 /api/write）或高风险请求（如 POST /order）做更激进的压制，可结合 RewriteRule 实现分流控制：
- 将写操作强制路由到专用低权重组：
RewriteCond %{REQUEST_METHOD} POST [NC]+RewriteRule ^/api/.*$ balancer://write-group%{REQUEST_URI} [P,L] - 在
write-group中设置极低loadfactor=1或极小max=5，形成事实上的流量压制带宽 - 配合
nofailover=On，避免因压制导致请求意外转到其他组
注意边界与替代方案
bybusyness 统计的是 Apache 自身维护的“代理层活跃连接”，不是后端应用的真实线程数或连接池占用。它无法替代应用层熔断（如 Hystrix）或网关级限流（如 Envoy 的 rate limit service）。若需毫秒级精确压制，应把逻辑下沉到服务网格或 API 网关；Apache 在此处的角色是轻量、稳定、可观测的入口层协调者，不复杂但容易忽略细节。
