apache mod_proxy_balancer支持四种常用调度算法：轮询（byrequests）、按流量（bytraffic）、按活跃连接数（bybusyness）、ip哈希+会话保持（stickysession），均通过proxyset lbmethod或stickysession指令配置，需配合balancermember和启用模块使用。
Apache 的 mod_proxy_balancer 模块支持多种请求分发策略，实际可用的调度算法不止四种，但生产中最常用、配置最明确的有四类：轮询（byrequests）、按流量（bytraffic）、按活跃连接数（bybusyness）、IP 哈希（byrequests + stickysession）。它们不是独立模块，而是通过 ProxySet lbmethod=xxx 指令启用，且必须搭配 mod_proxy_balancer 和后端 BalancerMember 使用。
轮询算法（byrequests）：最简稳态分发
按配置顺序循环分配请求，不依赖运行时状态，适合性能相近、处理耗时稳定的后端服务。
- 配置写法：
ProxySet lbmethod=byrequests - 无需额外参数，所有
BalancerMember默认权重为 1 - 若需差异化分发，可加
loadfactor实现权重轮询，例如：BalancerMember http://s1:80 loadfactor=3与BalancerMember http://s2:80 loadfactor=1将按 3:1 比例接收请求
按流量算法（bytraffic）：适配响应体大小差异
依据每个请求的响应字节数加权计算，适合 API 返回数据量波动大的场景（如报表接口 vs 简单状态查询）。
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 配置写法：
ProxySet lbmethod=bytraffic - 同样支持
loadfactor，权重影响的是“字节份额”而非请求数 - 注意：该算法不感知响应时间或连接数，仅统计已发出的响应体长度
最少连接数算法（bybusyness）：动态感知实时负载
Apache 内部维护各后端的当前活跃连接数（包括 keep-alive 连接），每次选连接数最少的节点转发，抗突发请求能力强。
- 配置写法：
ProxySet lbmethod=bybusyness - 天然适合短连接高并发或后端处理时长不均的业务
- 无需手动设权重，但可配合
loadfactor做粗粒度调节（例如某节点内存更大，可设更高权重提升其连接容量预期）
IP 哈希与会话保持（byrequests + stickysession）：保障用户连续性
Apache 不提供原生 IP 哈希算法模块，但可通过 stickysession 参数结合后端返回的 Cookie 或路径参数，实现等效效果。本质是将同一客户端“绑定”到固定后端。
- 配置关键项：
ProxySet stickysession=ROUTEID|JSESSIONID|PHPSESSID，其中值为后端设置的会话标识名 - 需在
BalancerMember中声明route，例如：BalancerMember http://s1:80 route=node1 - 后端应用必须在响应中写入含该 route 值的 Cookie（如
Set-Cookie: ROUTEID=.node1; Path=/），Apache 才能识别并复用 - 若后端未主动种 Cookie，也可用
RewriteRule提取 URL 中的 session 标识做代理重写
四种策略没有绝对优劣，选型取决于业务特征：轮询适合入门和测试；按流量适合内容分发类服务；按连接数适合交易、网关类高并发场景；会话保持则是有状态应用（如老系统、无共享 Session 架构）的刚需。所有配置都必须放在 <proxy balancer:></proxy> 块内，且 mod_proxy_balancer 必须已启用——用 httpd -M | grep proxy_balancer 可确认。
