Apache mod_proxy_balancer默认使用byrequests轮询算法,需同时启用proxy、proxy_http、proxy_balancer和lbmethod_byrequests模块,配置中必须在块内用ProxySet指定lbmethod=byrequests,并通过balancer-manager或curl验证分发是否均匀。
apache 的 mod_proxy_balancer 默认就用 byrequests(按请求数轮询),它最简单、最稳定,适合大多数 http api 或轻量级 web 服务。在虚拟主机(<virtualhost></virtualhost>)中配置,关键不是“怎么启用算法”,而是确保结构正确、模块就位、语法规范。
✅ 确认基础模块已启用
byrequests 依赖 mod_lbmethod_byrequests,不是可选插件,是独立模块。仅加载 proxy_balancer 不够:
# 检查是否全部就绪(必须同时出现以下四行) httpd -M | grep -E 'proxy|lbmethod_byrequests'
应看到:
proxy_module (shared) proxy_http_module (shared) proxy_balancer_module (shared) lbmethod_byrequests_module (shared)
-
Ubuntu/Debian:运行
sudo a2enmod proxy proxy_http proxy_balancer lbmethod_byrequests -
RHEL/CentOS:确认
/etc/httpd/conf.modules.d/00-proxy.conf中有LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so
重启 Apache 后再继续。
✅ 虚拟主机内标准配置写法
把负载均衡逻辑直接写在 <virtualhost></virtualhost> 块里,清晰且便于维护:
<virtualhost>
ServerName example.com
# 关闭正向代理(必须)
ProxyRequests Off
# 定义名为 mycluster 的 balancer,并指定 byrequests 算法
<proxy balancer:>
BalancerMember http://192.168.1.10:8080 loadfactor=2
BalancerMember http://192.168.1.11:8080 loadfactor=1
ProxySet lbmethod=byrequests
</proxy>
# 请求转发:所有 /api/ 开头的路径打到集群
ProxyPass "/api/" "balancer://mycluster/"
ProxyPassReverse "/api/" "balancer://mycluster/"
# 可选:透传原始 Host 头给后端
ProxyPreserveHost On
</virtualhost>
⚠️ 注意点:
-
BalancerMember的 URL 必须是完整协议+地址+端口(如http://...),不能只写域名或 IP; -
loadfactor是整数,0.5会被截断为0,该节点将完全不接收请求; -
ProxySet lbmethod=byrequests必须写在<proxy></proxy>块内,写在外部无效; -
ProxyPass和ProxyPassReverse的路径末尾斜杠要严格一致(/api/↔/api/),否则重写可能出错。
✅ 验证轮询是否真正在工作
别靠手动刷新页面判断——浏览器缓存、Keep-Alive、CDN 都会干扰。
⚠️ 已弃用 — 该技能已拆分为两个独立技能,以提升模块化程度:**webchat-https-proxy**(HTTPS/WSS 反向代理)和 **webchat-voi...**
推荐两种可靠方式:
-
看 balancer-manager 实时状态
先按规范启用管理页(需mod_status+ 显式放行):<location> SetHandler balancer-manager Require ip 192.168.1.0/24 </location>访问
http://example.com/balancer-manager,观察每个BalancerMember的 “Current Requests” 和 “Total Requests” 是否随请求逐步递增、比例接近loadfactor设置值。 -
用 curl 加连接关闭头测单次分发
curl -H "Connection: close" -sI http://example.com/api/test | grep X-Backend
前提是后端在响应头中写入标识(如
X-Backend: node1),这样能直观看到每次请求落到哪台机器。
✅ 补充:为什么不用其他算法?
-
bytraffic:适合大文件下载,但对 JSON API 响应体小、耗时差异大的场景不公平; -
bybusyness:更智能(按当前活跃请求数),但需要共享内存支持(建议启用mod_slotmem_shm),配置稍重; -
byrequests:无状态、无额外依赖、行为可预测,新上线首选。
只要后端节点性能相近、无明显长连接或慢请求堆积,byrequests 就是最稳妥的选择。










