Apache实现无损发布的核心是流量平滑切换、旧请求续行、新请求避让下线节点，依赖健康检查+动态权重+会话保持+后端优雅停机协同完成。

Apache 负载均衡实现无损发布，核心不是“完全不中断”，而是让流量平滑切换、旧请求继续完成、新请求不打到正在下线的节点。它依赖健康检查 + 权重动态调整 + 会话保持 + 后端配合，不是 Apache 单独能完成的魔法，而是一套协同机制。

---

✅ 无损发布的前提条件

• 后端服务支持优雅停机（如 Spring Boot 的 /actuator/shutdown 或 Tomcat 的 Graceful Shutdown）
• 后端提供轻量健康接口（如 GET /health 返回 200）
• Apache 已启用 mod_proxy_balancer、mod_lbmethod_byrequests（或 bytraffic）、mod_slotmem_shm 和 mod_proxy_hcheck（推荐，用于动态健康探测）
• 所有后端节点配置了唯一 route 参数（用于会话粘性）和一致的 stickysession 标识（如 JSESSIONID 或 CSID）

---

? 关键配置步骤（以 VirtualHost 内嵌方式为例）

1. 启用动态健康检查（避免请求打到已停止但未及时摘除的节点）

在 <Proxy> 块中为每个 BalancerMember 添加健康探测参数：

<Proxy balancer://appcluster>
  BalancerMember http://192.168.1.10:8080 route=node1 \
    loadfactor=5 \
    failonstatus=503,500 \
    hcmethod=GET \
    hcuri="/health" \
    hcpasses=2 \
    hcfails=2 \
    timeout=3 \
    retry=60
  BalancerMember http://192.168.1.11:8080 route=node2 \
    loadfactor=5 \
    failonstatus=503,500 \
    hcmethod=GET \
    hcuri="/health" \
    hcpasses=2 \
    hcfails=2 \
    timeout=3 \
    retry=60
  ProxySet lbmethod=byrequests
  ProxySet stickysession=JSESSIONID|jsessionid
</Proxy>

• failonstatus=503,500：返回这些状态码即判为不健康
• hcpasses=2：连续 2 次健康才恢复上线
• hcfails=2：连续 2 次失败即摘除
• retry=60：摘除后 60 秒再尝试探测（确保有足够时间完成 shutdown）

? 提示：/health 接口必须在应用 shutdown 流程中最后关闭——例如 Spring Boot 可配 management.endpoint.health.show-details=always 并确保 livenessState 在关闭前变为 DOWN。

2. 发布时执行“灰度下线”（人工或脚本触发）

无损发布的操作节奏是：

• Step 1：把待下线节点权重设为 0（Apache 仍保留其连接，但不再分发新请求）

  BalancerMember http://192.168.1.10:8080 route=node1 loadfactor=0 ...

  保存配置 → sudo systemctl reload apache2（软重载，不中断已有连接）

  

  Apache Superset Dashboard and SQL Exploration Skill

  Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

  下载

• Step 2：等待该节点上活跃连接自然耗尽（可通过 balancer-manager 页面或 curl http://localhost/balancer-manager?auto=1 查看 Busy 和 Ready 数）

• Step 3：确认 Busy=0 后，再手动停掉该后端服务（如 systemctl stop myapp-node1）

• Step 4：验证日志无 503/超时，且用户无感知（尤其注意含长连接、上传、轮询 polling 的场景）

3. 配合会话与连接管理

• 使用 stickysession=JSESSIONID|jsessionid 确保用户会话不漂移
• 若后端支持 Session 复制（如 Tomcat cluster），可降低对 sticky 的依赖；否则 sticky 是刚需
• ProxyPass / balancer://appcluster/ disablereuse=off（默认即可，复用连接提升性能）
• 不建议加 acquire=3000 等硬性连接等待，会阻塞新请求

4. 监控与验证入口（可选但强烈推荐）

开启 balancer-manager 用于实时观察（仅限内网或带鉴权）：

<Location "/balancer-manager">
  SetHandler balancer-manager
  Require ip 127.0.0.1 192.168.1.0/24
  # 或用 auth_basic + htpasswd 做简单保护
</Location>

访问 http://your-apache/balancer-manager 可直观看到各节点状态、权重、当前请求数、错误数、是否 in recycle 等。

---

⚠ 常见坑点提醒

• loadfactor=0 ≠ 立即摘除：Apache 仍会转发已建立连接的后续请求（如 HTTP/1.1 keep-alive），这是无损的关键，但也意味着你得等连接释放完
• retry 时间必须大于后端 shutdown 超时时间（如 Tomcat shutdown-timeout="30" → retry ≥ 45）
• mod_proxy_hcheck 模块在 Apache 2.4.41+ 才稳定支持 hcuri 和 hcmethod，旧版本只能靠 ping 或 failonstatus 被动判断
• 如果后端没有 /health 接口，可用 ping 方式（但不如 HTTP 精准）：hcmethod=HEAD hcuri="/" hcpasses=1 hcfails=1
• SSL 终止在 Apache？确保 ProxyPassReverse 正确重写 Location 和 Set-Cookie: Secure 头部，否则跳转或登录态异常

---

不复杂但容易忽略。真正决定无损效果的，是后端是否“可预测地退出”，而不是 Apache 配得多漂亮。