apache负载均衡调度算法不生效，根本原因是模块未完整加载（如缺失mod_lbmethod_*或mod_slotmem_shm）、proxyset lbmethod配置位置错误或拼写不准、健康检查将节点标记为err/disab导致无可用节点参与调度，以及proxypass路径配置不当绕过balancer逻辑。
apache 负载均衡调度算法不生效，通常不是“配了没用”，而是配置未被正确加载、模块缺失、逻辑冲突或运行时状态异常。问题往往藏在细节里，比如一个模块没启、一个参数拼错、或健康检查把节点全摘了——表面看是算法失效，实际是流量根本没走到调度环节。
模块是否完整启用
mod_proxy_balancer 和对应 lbmethod 模块必须显式加载，否则 ProxySet lbmethod=xxx 会被忽略，Apache 默认回退到轮询（byrequests），且不报错。
- 运行 apachectl -M | grep -E "(proxy|balancer|lbmethod|slotmem)"，确认以下模块全部存在：
mod_proxy、mod_proxy_balancer、mod_slotmem_shm（必需！缺它会导致状态不同步）、mod_lbmethod_byrequests（轮询）、mod_lbmethod_bybusyness（最少连接）等 - 若 mod_lbmethod_bybusyness 缺失，需手动添加：
LoadModule lbmethod_bybusyness_module modules/mod_lbmethod_bybusyness.so - 注意：mod_slotmem_shm 是共享内存基础，缺失时 /balancer-manager 界面可能空白，粘性会话失效，算法状态无法跨进程同步
配置语法与作用域是否正确
Apache 不校验 lbmethod 参数是否匹配已加载模块，也不验证 BalancerMember 是否真实可达——configtest 只过语法，不验逻辑。
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 检查 ProxySet lbmethod=xxx 是否写在
块内，且紧邻 BalancerMember 行之后；若放在 VirtualHost 外或嵌套错误位置，会被忽略 - 确认算法名拼写准确：
byrequests（轮询）、bybusyness（最少连接）、bytraffic（加权流量）、heartbeat（需额外模块）——大小写敏感，无下划线 - 权重轮询（bytraffic）需配合 loadfactor 使用；最少连接（bybusyness）不认 loadfactor，设了也无效
运行时状态是否真实可用
即使配置正确，节点若被健康检查标记为 DOWN 或处于热备（status=+H），算法也不会将请求分发过去——你看到的“不生效”，其实是没节点可选。
- 访问 /balancer-manager（需 Location 开放），查看各节点状态：OK、INIT、ERR、DISAB、PROBE、HOTSTANDBY。只有标 OK 的节点参与调度
- 检查健康检查配置：
hcmethod=GET、hcuri=/health、hcinterval=10、hcfail=3 —— 若后端实际响应的是 /actuator/health 且返回 200，但 hcuri 配成 /healthz，节点就会持续 ERR - 直连后端验证：
curl -I http://192.168.1.101:8080/health 看是否返回 200；再用 telnet 192.168.1.101 8080 确认四层连通性
请求路径与转发规则是否绕过负载均衡
常见误操作会让请求根本不经过 balancer:// 逻辑，自然不触发任何调度算法。
- 检查 ProxyPass 是否覆盖完整路径：
ProxyPass / balancer://mycluster/ —— 末尾斜杠必须一致，否则子路径重写失败，可能降级为静态文件服务 - 确认没有其他 ProxyPass 规则优先匹配（如 ProxyPass /api/ http://backup/），导致部分流量被提前截断
- 查看 access_log 中请求目标 IP：若日志里全是后端某一台的地址，说明流量被固定路由（如 ip_hash 或 route= 强制绑定），而非按算法分发
