轮询是mod_proxy_balancer默认策略，启用只需加载模块、使用balancer://协议并配置BalancerMember；需验证模块加载、节点状态、权重及健康检查是否正常，避免静默退化或流量倾斜。
Apache mod_proxy_balancer 轮询模式怎么启用
轮询（Round Robin）是 mod_proxy_balancer 的默认负载策略，只要启用了模块并配置了 <proxy balancer:></proxy>，不显式指定 lbmethod 就是轮询。关键不是“怎么设”，而是“怎么确认它真在轮询”。
常见错误是只配了 ProxyPass 却没加载 mod_proxy_balancer，导致请求全发给第一个后端——Apache 会静默退化为普通代理，不报错也不告警。
- 确保已启用模块：
a2enmod proxy_balancer（Debian/Ubuntu）或在httpd.conf中取消注释LoadModule proxy_balancer_module modules/mod_proxy_balancer.so - 必须使用
balancer://协议名定义后端组，不能只写http://列表 - 检查
apachectl -M | grep proxy输出中是否含proxy_balancer_module
轮询配置里哪些参数会影响实际分发行为
lbmethod=byrequests 是轮询的底层标识，但真正影响分发节奏的是后端节点状态和权重。即使没改 lbmethod，以下设置也会让轮询“看起来不均匀”：
-
loadfactor值不同时，Apache 按权重比例分配请求数，比如loadfactor=2和loadfactor=1的节点，实际收到的请求数比接近 2:1，不再是严格 1:1 -
status=+H（热备）或status=+D（禁用）会让节点退出轮询队列，剩余节点继续按比例承接 -
ping参数失效时（如后端响应慢），Apache 可能临时剔除节点，造成短时流量倾斜
示例配置片段：
<Proxy balancer://mycluster>
BalancerMember http://192.168.1.10:8080 loadfactor=3
BalancerMember http://192.168.1.11:8080 loadfactor=1
BalancerMember http://192.168.1.12:8080 status=+D
</Proxy>
ProxyPass / balancer://mycluster/ lbmethod=byrequests
如何验证轮询是否生效且无隐藏故障
靠日志查 %{BALANCER_NAME}e 或 %{BALANCER_WORKER_ROUTE}e 环境变量最直接，但默认不记录。别依赖浏览器反复刷新看 IP 变化——HTTP Keep-Alive、浏览器缓存、CDN 都会干扰判断。
- 临时关闭 Keep-Alive：
KeepAlive Off，并在测试请求头加Connection: close - 用
curl -H "Connection: close" -sI http://your-proxy/ | grep X-Backend，前提是后端在响应头写入标识（如X-Backend: node1） - 开启
mod_status并访问/balancer-manager，页面里能看到每个 worker 的“Current Requests”和“Transferred”计数，连续刷新观察增量是否均衡 - 注意：如果某节点 “Elected” 数远高于其他，但 “Transferred” 几乎为 0，说明它持续失败（503/超时），已被标记为“故障”，轮询已自动绕过它
轮询模式下 session 黏连问题怎么破
轮询本身不维持 session，用户第二次请求可能落到不同后端，导致登录态丢失。这不是轮询的 bug，而是设计如此。解决方式取决于应用层是否支持共享 session：
- 后端用 Redis/Memcached 存 session，所有节点读写同一存储，这是最干净的解法
- Apache 层启用 sticky session：
BalancerMember ... route=node1+ProxySet stickysession=ROUTEID，要求后端在响应 Set-Cookie 中带ROUTEID=node1 - 避免用
path=/的 Cookie 冲突：多个后端若都写同名 Cookie，浏览器会覆盖，建议后端生成 Cookie 时加上唯一前缀或使用jsessionid标准格式
真正容易被忽略的是健康检查粒度——ping 默认只检查 HTTP 状态码，如果后端应用进程活着但 session 模块崩溃，Apache 仍会把请求轮询过去，结果返回 500。得配合自定义 ping 脚本或应用级探针。
