Apache mod_proxy_balancer 本身不支持基于后端CPU空闲率的负载分配，仅支持byrequests、bytraffic、bybusyness等原生算法；bybusyness仅依据代理层连接数，无法获取系统级指标。
Apache mod_proxy_balancer 本身不支持基于后端节点 CPU 空闲率的负载分配。它提供的原生负载均衡算法（byrequests、bytraffic、bybusyness）中：
-
bybusyness是按当前正在处理的请求数（pending requests） 判断空闲程度，属于 Apache 代理层的“连接级”忙闲感知，不读取或依赖后端服务器的系统指标（如 CPU、内存、负载均值）； - 所有健康检查（如
hcmethod=GET+hcexpr）仅验证 HTTP 响应状态或简单响应内容，无法获取并解析/proc/loadavg或top类系统数据。
✅ 所以：纯靠 mod_proxy_balancer 配置，无法实现“按 CPU 空闲率”分发请求。
但你可以通过以下两种可行路径间接达成目标：
✅ 方案一：后端暴露健康/指标接口 + 自定义健康检查表达式（推荐）
让每个后端服务（如 Tomcat、Spring Boot 应用）提供一个轻量 HTTP 接口，返回自身 CPU 空闲率（例如 JSON：{"cpu_idle": 72.4}），Apache 通过 ProxyHCExpr 解析该值，并结合 hcinterval 主动轮询，再配合 status=+H 实现“动态权重降级”。
操作步骤：
-
后端添加指标接口（示例 Spring Boot）
@GetMapping("/health/cpu") public Map<String, Object> cpuHealth() { double idle = ManagementFactory.getOperatingSystemMXBean() .getSystemCpuLoad() * 100; // 注意：这是使用率，idle ≈ 100 - 使用率 return Map.of("cpu_idle", 100 - idle); } -
Apache 启用
mod_proxy_hcheck（需 Apache ≥ 2.4.43）
在<proxy></proxy>块中为每个节点配置：<Proxy "balancer://mycluster"> BalancerMember http://192.168.1.10:8080 \ loadfactor=10 \ hcmethod=GET \ hcinterval=15 \ hcuri="/health/cpu" \ hcexpr="%{REQUEST_STATUS} == 200 && %{RESPONSE_JSON:cpu_idle} > 30" BalancerMember http://192.168.1.11:8080 \ loadfactor=10 \ hcmethod=GET \ hcinterval=15 \ hcuri="/health/cpu" \ hcexpr="%{REQUEST_STATUS} == 200 && %{RESPONSE_JSON:cpu_idle} > 30" </Proxy>⚠️ 注意：
%{RESPONSE_JSON:xxx}是 Apache 2.4.49+ 支持的语法；低版本需改用正则匹配hcexpr（如hcexpr="%{REQUEST_STATUS} == 200 && %{RESPONSE_BODY} =~ /\"cpu_idle\"\s*:\s*(\d+)/ && $1 > 30"）。 -
效果逻辑：
- 当某节点
cpu_idle ，<code>hcexpr不满足 → Apache 将其标记为DOWN→ 请求自动绕过； - 节点恢复 idle > 30% 后，经
retry=60秒（默认）自动恢复服务； - 结合
loadfactor和bybusyness，可进一步微调流量倾向。
- 当某节点
✅ 方案二：外挂调度器 + 动态重写 balancer 配置（适合强定制场景）
用外部脚本（Python/Bash）定时采集各后端 CPU 数据，生成带 loadfactor 的新 <proxy></proxy> 配置，再触发 Apache 重载。
关键动作：
- 每 30 秒执行采集脚本，调用
top -bn1 | grep 'Cpu(s)'或mpstat计算 idle； - 根据 idle 值映射
loadfactor（例如：idle 80% →loadfactor=5；idle 20% →loadfactor=1）； - 写入临时配置文件（如
/etc/apache2/mods-enabled/balancer-dynamic.conf）； - 执行
apachectl graceful平滑重载。
优点：完全可控，支持任意指标组合（CPU + 内存 + 响应延迟）；
缺点：需额外运维、注意配置并发写入安全、Apache reload 有毫秒级抖动。
❌ 不可行的方式（常见误区）
- 直接在
BalancerMember中写loadfactor=${cpu_idle}—— Apache 不解析 Shell 变量； - 期望
mod_proxy_balancer自动读取/proc/或运行ssh user@node 'cat /proc/loadavg'—— 它没有系统级探针能力； - 用
mod_status或balancer-manager页面展示 CPU —— 这只是监控界面，不参与调度逻辑。
Apache 的角色是应用层反向代理与请求路由，不是资源编排平台。真正按 CPU 调度，更适合交给 Kubernetes HPA、Nginx Plus（需商业许可）、或专用服务网格（如 Envoy + Prometheus）。若坚持用 Apache，方案一最实用、安全、易维护。
