Apache负载均衡通过mod_proxy_balancer配合健康检查实现故障转移：自动剔除宕机节点并转发请求至存活实例；需启用proxy模块、配置balancer组、设置retry/ping/failonstatus等参数，并建议外置Session及结合DNS/SLB/Consul等增强容错。
apache 负载均衡本身不直接处理故障转移，它依赖反向代理层（如 mod_proxy_balancer）配合健康检查机制，在后端节点宕机时自动剔除异常实例，把请求转向存活节点——这是最常用、最轻量的故障转移实现方式。
启用并配置 mod_proxy_balancer
确保 Apache 启用了必要模块：
- a2enmod proxy proxy_http proxy_balancer（Debian/Ubuntu）
- 或手动在 httpd.conf 中加载：
LoadModule proxy_module modules/mod_proxy.so等
在虚拟主机或主配置中定义负载均衡组：
<Proxy "balancer://mycluster"><br> BalancerMember http://192.168.1.10:8080 route=server1 retry=60<br> BalancerMember http://192.168.1.11:8080 route=server2 retry=60<br> BalancerMember http://192.168.1.12:8080 route=server3 status=+D</Proxy>
关键参数说明：
- retry=60：节点失败后，60 秒内不尝试转发请求（避免雪崩）
- status=+D：手动禁用某节点（如维护时），无需重启 Apache
- 可加
ping=5让 Apache 每 5 秒发一个 HEAD 请求探测健康状态
健康检查必须开启且合理设置
默认情况下，mod_proxy_balancer 只在请求失败时标记节点为“失效”，属于被动检测。要应对突发宕机，建议主动健康检查：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 添加
ping=5参数，让 Apache 定期探测后端 HTTP 响应码（需后端返回 2xx） - 搭配
failonstatus=500,503，当后端返回指定错误码时立即下线该节点 - 避免使用过短的
ping间隔（如 <2s），防止探测压垮后端
注意：健康检查路径需轻量，推荐后端提供 /health 接口，仅校验进程存活与基本依赖（如 DB 连通性），不执行业务逻辑。
会话保持与故障转移的兼容处理
若应用有 Session 依赖，启用 sticky session（stickysession=ROUTEID）时需注意：
- 节点宕机后，原绑定该节点的会话会丢失，用户可能需重新登录
- 更稳妥的方式是将 Session 外置到 Redis 或数据库，彻底解耦 Apache 和后端状态
- 若必须用 sticky，可在 BalancerMember 中加上
redirect=server2，当 server1 宕机，其会话自动重定向到 server2（需后端支持 session 复制或共享）
配合外部工具增强容错能力
Apache 自身不具备集群级故障发现和自动扩缩容能力。生产环境建议叠加以下手段：
- 前端加一层 DNS 轮询或云厂商 SLB（如阿里云 ALB），作为 Apache 实例的入口，防止单台 Apache 成为瓶颈
- 用 Consul 或 ZooKeeper 管理后端服务注册，再通过脚本动态更新 Apache 的 balancer 配置并 reload（需谨慎控制 reload 频率）
- 对关键业务，Apache 后端不要直连应用服务器，而是接入 Envoy 或 Nginx 作为二级负载层，利用其更精细的熔断、限流、重试策略
