如何配置HAProxy高可用基础设施 实现超时请求自动转发避免服务超时

一、HAProxy 直接配置实现超时自动重试路由 #

你需要的超过100ms自动切换后端的逻辑可以通过HAProxy自带的重试+超时机制直接实现，核心配置如下：

# 后端配置段
backend tier0_backend
    balance leastconn
    # 单台后端请求超时时间设为100ms，匹配你的阈值
    timeout server 100ms
    # 最多重试2次（总共尝试3台不同后端，可根据你的集群大小调整）
    retries 2
    # 重试触发条件：连接错误、服务器超时、5xx响应、服务器被标记为下线
    retry-on conn-failure server-timeout 5xx-server-error down
    # 关键配置：重试时不选择之前已经失败过的服务器
    option redispatch 1
    # 健康检查配置，提前剔除异常节点，减少触发重试的概率
    option httpchk GET /health
    http-check expect status 200
    server srv1 10.0.0.1:8080 check inter 2s rise 2 fall 3
    server srv2 10.0.0.2:8080 check inter 2s rise 2 fall 3
    # 更多后端节点...

配置注意事项：

• 仅对幂等请求（GET/HEAD/OPTIONS等）默认开启重试，如果涉及POST/PUT等写请求，需要在Java应用侧实现请求幂等校验后，再通过ACL规则限制重试的请求方法，避免重复提交数据。
• 调整timeout server参数时要和业务P99耗时匹配，避免把正常的慢请求误判为异常触发不必要的重试。

二、配套技术栈优化（贴合你方技术栈） #

• Java业务侧：实现优雅下线逻辑，收到下线信号后先把健康检查接口返回503，等待3~5秒（超过HAProxy健康检查间隔）再停止服务，避免HAProxy还没把节点剔除时的请求分发到正在下线的节点。另外可接入熔断器组件（比如Resilience4j），本地快速失败的请求直接返回5xx触发HAProxy重试。
• Azure侧：如果使用Azure虚拟机/应用服务作为后端，可以把HAProxy健康检查和Azure的自动扩缩容规则联动，异常节点自动剔除替换，进一步降低故障节点存在的时间。
• MySQL侧：优化慢查询，把超过80ms的SQL全部优化（留20ms的业务处理余量），避免因为存储层慢导致后端整体响应超时触发不必要的重试。

三、边界场景说明 #

• 重试次数建议不要超过3次，总超时时间控制在400ms以内，避免重试风暴导致整个集群雪崩。
• 当所有后端节点都异常时，最终还是会返回超时响应，符合你方的预期。

内容的提问来源于stack exchange，提问作者BITSSANDESH