byrequests算法通过静态加权轮询实现无状态集群均衡，需启用对应模块、正确定义balancer组并设置lbmethod=byrequests；权重依据资源合理配置，配合健康检查与监控微调，确保高效可靠。

用 byrequests 算法做无状态集群均衡，核心是让请求按预设权重均匀落到各后端节点，不依赖会话、不追踪状态，适合 Spring Boot、静态服务或 RESTful API 这类纯无状态 Java 应用。它本身简单可靠，但要“高效”，关键不在算法多智能，而在配置扎实、权重合理、故障响应及时。

确保模块就位与基础结构正确

byrequests 是默认调度算法，但必须显式启用对应模块并构建合法 balancer 结构：

• 确认已加载 mod_proxy、mod_proxy_http、mod_proxy_balancer 和 mod_lbmethod_byrequests（Ubuntu 用 a2enmod lbmethod_byrequests，RHEL 用 yum install mod_lbmethod_byrequests）
• balancer 定义必须完整，不能只写 ProxyPass / balancer://mycluster，而要先声明组：
  

  <Proxy balancer://mycluster><br>  BalancerMember http://t1:8080 loadfactor=5<br>  BalancerMember http://t2:8080 loadfactor=3<br></Proxy>

• 必须指定 lbmethod=byrequests，例如：ProxyPass / balancer://mycluster/ lbmethod=byrequests，否则可能回退到未定义行为

用 loadfactor 实现可预期的流量分配

byrequests 按“已分发请求数”轮询，loadfactor 决定每个节点在一轮中被选中的相对次数。比如两个节点 loadfactor=5 和 loadfactor=3，每轮共 8 次请求，前者拿 5 次，后者拿 3 次——这是静态加权，不是动态适配，所以权重设置要有依据：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• 参考后端实际资源：CPU 核数、JVM 堆大小、线程池容量。若 node1 是 8C16G，node2 是 4C8G，初始权重可设为 2:1
• 避免极端值：loadfactor=1 是默认值，设 loadfactor=100 并不比 10 更“强”，反而易导致某节点瞬间积压大量请求
• 无状态场景下，不建议设 route 或 sticky，否则破坏无状态性；如需会话保持，请换用其他架构（如 Redis 共享 session）

配合健康检查与重试，保障均衡不落空

单纯轮询无法应对节点临时抖动，byrequests 的高效必须建立在“可用节点真实可用”基础上：

• 给每个 BalancerMember 加上 retry=15：节点返回错误或超时后，15 秒内不再派发新请求，避免雪崩
• 加上 ping=5：转发前先发 HEAD 探测，5 秒无响应则本次跳过该节点（不计入 retry，仅单次规避）
• 加上 timeout=10 和 maxattempts=2：单次请求最多等 10 秒，失败后自动尝试下一个节点（需 lbmethod=byrequests 才生效）
• 慎用 failonstatus：无状态服务常返回 500/503，可加 failonstatus=500-599 主动剔除异常节点，但注意它只对完整响应生效，连不上时靠 timeout 和 ping

监控与微调：让静态权重不僵化

byrequests 本身不感知后端负载，但你可以用轻量方式让它“近似动态”：

• 开启 /balancer-manager 页面（限制 IP 访问），手动观察各节点当前请求数、失败数、权重是否匹配实际吞吐
• 写个简单脚本，定时 curl 各后端 /actuator/health 或自定义指标端点，若某节点响应时间 > 2s 或错误率 > 5%，就用 POST 调用 /balancer-manager?b=mycluster&w=http://t1&dw=2 把它的权重临时调低
• 权重下调后，不要立刻归零，保留 loadfactor=1 维持少量灰度流量，便于验证恢复情况