Apache负载均衡保障业务持续可用的核心是构建“故障可感知、流量可切换、节点可自愈”闭环机制，需协同主动健康检查（ProxyHCExpr+hcexpr）、会话保持（stickysession+nofailover=Off）与多级超时重试（timeout/acquire/maxattempts），并接入balancer-manager和Prometheus实现监控与人工干预。
要保障业务持续可用，Apache 负载均衡不能只做简单转发，关键在于构建“故障可感知、流量可切换、节点可自愈”的闭环机制。核心是健康检查 + 会话保持 + 故障快速隔离三者协同。
启用主动健康检查并设置合理探测策略
仅靠 status=+H 标记不够，必须配合 ProxyHCExpr 定义真实探测逻辑，否则节点宕机后仍会转发请求：
- 在配置中定义健康检查表达式，例如检测 HTTP 状态码和响应体内容：
ProxyHCExpr ok {%{REQUEST_STATUS} == 200 && %{CONTENT} =~ /"status":"ok"/} - 为每个 BalancerMember 添加健康检查模板：
BalancerMember http://node1:8080 hcexpr=ok retry=10 timeout=3
其中 retry=10 表示连续失败 10 次才标记为 down，timeout=3 控制单次探测超时，避免卡住连接 - 建议使用
/healthz这类轻量端点，避免调用业务接口影响性能
配置会话保持与故障自动漂移
用户会话不中断，是持续可用的直观体现。需兼顾粘性和容错：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 启用基于 Cookie 的粘性路由：
ProxySet stickysession=ROUTEID|JSESSIONID|PHPSESSID
注意：后端需在响应中写入含 route 参数的 Cookie，如Set-Cookie: JSESSIONID=abc123.node1 - 添加
nofailover=Off（默认值），允许 Apache 在主节点失效时，将请求临时转发给其他健康节点，而非直接报错 - 若业务强依赖会话，建议后端同步 session 到 Redis 或数据库，避免单点丢失
设置多级超时与重试保护
防止雪崩传播，让 Apache 成为稳压阀：
- 在 ProxyPass 中统一控制连接生命周期：
ProxyPass / balancer://app/ timeout=5 retry=10 acquire=3000
timeout=5 是后端响应超时；acquire=3000 是从连接池获取连接的毫秒等待上限 - 限制单个请求最大重试次数：
ProxySet maxattempts=2（放在块内），避免反复打挂同一故障节点 - 对关键路径（如支付、登录）单独配置更保守参数，例如
timeout=8，留出后端处理余量
接入实时状态监控与人工干预通道
持续可用不仅是自动机制，更要有人可介入的兜底能力：
- 启用
balancer-manager并严格限制访问源：<Location "/balancer-manager"><br> SetHandler balancer-manager<br> Require ip 10.0.1.0/24<br></Location>
- 配合 Prometheus + Apache Exporter 抓取
mod_status指标，重点关注lbstatus（各节点权重/状态）、requests、transferred - 运维可通过 manager 页面手动下线异常节点（点击 “Disable”），或临时提升某节点权重应对突发流量
