retry参数必须配置在BalancerMember或ProxySet中，而非ProxyPass末尾；需配合failonstatus和timeout才能触发节点冷却与自动恢复，有效应对后端瞬时抖动。
在 apache 虚拟主机中配置 retry 参数，不能直接写在 proxypass 指令行末尾——它不是 proxypass 的参数，而是作用于后端节点（balancermember 或 proxyset）的恢复控制项。要真正实现对后端瞬间抖动（如短暂 503、gc 卡顿、健康检查间隙）的容错，必须把它放在负载均衡组内，并配合故障判定机制一起生效。
retry 的实际位置和写法
retry 必须定义在 <Proxy balancer://...> 块中，作为 BalancerMember 的属性或通过 ProxySet 统一设置：
- 单节点指定（推荐，灵活可控）：
<Proxy balancer://api>
BalancerMember http://10.0.1.10:8080 retry=10
BalancerMember http://10.0.1.11:8080 retry=10
</Proxy> - 统一设置（适合同质后端）：
<Proxy balancer://api>
BalancerMember http://10.0.1.10:8080
BalancerMember http://10.0.1.11:8080
ProxySet retry=10
</Proxy>
注意：仅写 ProxyPass / balancer://api/ retry=10 是无效的，Apache 会忽略该参数。
retry 单独配置不生效，必须搭配 failonstatus 和 timeout
retry 不是“自动重试请求”，而是节点被标记为 down 后的冷却等待时间。触发 down 状态，依赖以下两个前提：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
failonstatus=500,502,503,504：显式把网关类错误纳入故障判定，否则即使返回 503，节点也不会被踢出 -
timeout=3（或ttl=30）：防止单次请求卡死太久，拖慢整体响应；超时也会触发失败计数
完整示例（放入虚拟主机配置中）：
<VirtualHost *:80>ServerName api.example.com
<Proxy balancer://api>
BalancerMember http://10.0.1.10:8080 retry=10
BalancerMember http://10.0.1.11:8080 retry=10
ProxySet failonstatus=500,502,503,504 timeout=3
</Proxy>
ProxyPass / balancer://api/
ProxyPassReverse / balancer://api/
</VirtualHost>
retry 值怎么设才合理
太小容易反复踢出，太大浪费容量。参考依据是后端典型抖动持续时间：
- 无状态 HTTP 服务（如 Spring Boot REST API）：设
retry=5–15，覆盖常见 GC STW 或连接池临时耗尽 - 带事务或会话的后端（如含 Session 复制的 Tomcat 集群）：设
retry=15–30，留足清理时间和连接重建窗口 - 若后端有主动健康探测（如
ping=3），可适当降低 retry（如 8–12），因探测比被动失败更快感知恢复
验证 retry 是否起效
最简验证方式：
- 用 curl 故意让某台后端短暂返回 503：
curl -s -o /dev/null -w "%{http_code}" -X GET http://10.0.1.10:8080/health - 访问 Apache 的
/balancer-manager页面（需启用并授权），观察对应节点状态是否变为 down (retry in 10 sec) - 等待设定秒数后，状态应自动变回 OK，且新请求开始命中该节点
