Apache mod_proxy_balancer流量不均主因是默认轮询或静态权重未适配新节点能力且缺实时负载反馈；应改用bybusyness算法、合理设置loadfactor、启用健康检查。
apache mod_proxy_balancer 本身不会自动感知新节点加入后“该分多少流量”，扩容后流量不均，根本原因在于：默认轮询（byrequests）或静态权重未适配新节点能力，且缺乏实时负载反馈机制。解决关键不是“加一台机器就自动分走1/n流量”，而是让 apache 能合理评估、动态响应、平滑过渡。
以下三点是真正有效的解决路径：
✅ 用 bybusyness 替代 byrequests，让调度基于真实连接压力
bybusyness 算法按每个后端当前活跃连接数（pending requests）分配请求，天然适应节点性能差异和动态扩缩容。
- 新节点刚上线时连接数为0，会快速承接流量；
- 高负载老节点连接堆积，自动被“冷落”；
- 不依赖人工预设权重，避免扩容后人为调参滞后。
配置示例：
<Proxy balancer://api>
BalancerMember http://192.168.1.10:8080
BalancerMember http://192.168.1.11:8080
BalancerMember http://192.168.1.12:8080 # 新增节点
ProxySet lbmethod=bybusyness
ProxySet timeout=5 retry=60
</Proxy>✅ 给新节点设置初始 loadfactor，避免“过载涌入”
即使用了 bybusyness，若新节点硬件明显更强（如 CPU/内存翻倍），可配合 loadfactor 主动引导更多流量：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
loadfactor=2表示它“理论上能处理2倍于基准节点”的连接数； - Apache 内部会将它的“有效连接数”按比例折算（例如实际连接数×0.5），从而提升被选中的概率；
- 不要设过高（如
loadfactor=10），否则可能瞬间压垮新实例。
建议值参考：
- 同规格节点：
loadfactor=1（默认，可省略） - 8C16G 节点对 4C8G：
loadfactor=2 - 云上弹性实例（如 AWS m6i.2xlarge vs m6i.xlarge）：按 vCPU 比例设
✅ 配合健康检查 + retry 控制，防止“假扩容”干扰均衡
扩容后若新节点服务未完全就绪（如 Spring Boot 启动中、数据库连接未建好），bybusyness 仍会把请求发过去，导致超时或错误，进一步拉高其他节点负载。
必须启用主动探测，确保只把流量导给真正健康的实例：
BalancerMember http://192.168.1.12:8080 \
hcmethod=GET \
hcuri="/actuator/health" \
hcexpr="%{REQUEST_STATUS} == 200" \
hcinterval=10 \
retry=30说明：
- 每10秒探活，连续30秒无200响应则标记为
DOWN，不再参与调度； - 恢复200后立即重新加入，无需重启 Apache；
-
/actuator/health是 Spring Boot 默认健康端点，轻量且可靠。
不复杂但容易忽略
