byrequests算法实现无状态均衡需显式启用模块、禁用会话粘滞、确保后端无状态，并通过响应头、健康检查和管理界面验证轮询分发与故障转移。
用 byrequests 算法实现无状态均衡，关键在于不依赖会话绑定、不保存客户端状态，让每次请求都独立参与轮询分发。它本身是无状态的默认策略，但要真正落地为“可靠无状态”，需避开常见配置陷阱。
确保后端服务本身无状态
无状态均衡的前提是后端不依赖本地会话存储：
- Tomcat 或 Spring Boot 应禁用本地 HttpSession 存储，改用外部 Session 管理（如 Redis + Spring Session）或完全使用 JWT/Token 认证
- 移除配置中的
ProxySet stickysession=JSESSIONID—— 这一行会强制绑定会话，破坏无状态性 - 后端应用日志或监控中不应出现 “session not found” 或重定向到登录页等会话丢失现象，否则说明前端仍隐式依赖粘滞
正确启用并验证 byrequests 调度器
byrequests 不是自动生效的，必须显式加载模块并指定算法：
- 确认已启用
mod_lbmethod_byrequests（Ubuntu 用a2enmod lbmethod_byrequests；CentOS 用yum install mod_lbmethod_byrequests） - 在
<proxy></proxy>块中明确设置：ProxySet lbmethod=byrequests - 避免遗漏
mod_proxy_balancer和mod_proxy_http—— 缺任一模块，lbmethod将被忽略 - 可通过
apachectl -M | grep lbmethod验证模块是否载入成功
后端节点配置要简洁一致
每个 BalancerMember 应只保留必要参数，避免引入隐式状态逻辑：
- 基础写法：
BalancerMember http://backend1:8080—— 无 weight、无 route、无 status=disabled - 如需权重，用
loadfactor=2而非weight=2（后者属旧版语法，部分版本不识别） - 禁用
route=xxx和redirect=xxx，这些字段会触发会话粘滞逻辑，即使没配stickysession - 所有后端应监听相同路径、返回相同 CORS/Cache-Control 头，避免因响应差异导致客户端行为不一致
验证均衡效果与故障转移行为
无状态不是配完就完事，得验证请求是否真按轮询分发且失败时能跳过：
- 用
curl -I http://lb-host/health连续发起 10 次，检查X-Backend响应头（可由后端注入）是否交替出现 backend1/backend2 - 临时停掉 backend1，再发请求，应全部落到 backend2，且不报 503 —— 这要求配置含
retry=15和maxattempts=2 - 访问
/balancer-manager页面（需安全启用），查看各成员的 “Current Requests” 是否接近相等，且无持续为 0 或长期 pending 的异常值
