HAProxy故障转移如何做

在 HAProxy 中，“故障转移（Failover）”通常不是单一配置，而是多层机制组合的结果。下面按「最常见、最实用的方式」给你讲清楚，并附配置示例。

一、HAProxy 自身做的故障转移（后端级别）

1️⃣ 后端健康检查 + 自动剔除

这是最基础的故障转移。

backend app
    option httpchk GET /healthz
    server app1 10.0.0.1:8080 check
    server app2 10.0.0.2:8080 check

✅ 效果：

• 某个后端不健康 → 自动从转发列表剔除
• 恢复后自动加回

常用参数：

check inter 2000 rise 2 fall 3

• inter：检查间隔
• fall：失败几次算宕机
• rise：成功几次算恢复

2️⃣ 主备模式（Active + Backup）

明确“主挂了才用备”

server main   10.0.0.1:8080 check
server backup 10.0.0.2:8080 check backup

✅ 特点：

• 只有 main 不可用，backup 才接管
• 适合 DB、老系统、冷备

3️⃣ 多活 + 负载均衡（最常见）

默认就是故障转移

server s1 10.0.0.1:8080 check
server s2 10.0.0.2:8080 check
server s3 10.0.0.3:8080 check

• 一个挂了，流量自动走其他
• 无感知切换

二、HAProxy 本身的故障转移（HAProxy 宕机）

HAProxy 本身也会挂，所以要双 HAProxy

✅ 方案：Keepalived + VIP

        VIP (10.0.0.100)
         /        \
   HAProxy A    HAProxy B

Keepalived 示例

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    virtual_ipaddress {
        10.0.0.100
    }
}

✅ 效果：

• A 挂 → VIP 漂到 B
• 客户端无感知

三、高级故障转移场景

1️⃣ 跨机房故障转移

server local1 10.0.1.1:8080 check
server remote1 10.0.2.1:8080 check backup

或用 nginx / dns / anycast 在更上层做切换。

2️⃣ 应用层故障转移（返回错误码）

option httpchk GET /healthz
http-check expect status 200

非 200 即认为失败。

3️⃣ 连接级重试（减少瞬时失败）

retries 3
option redispatch

四、典型生产架构（推荐）

DNS / SLB
   |
Keepalived VIP
   |
HAProxy (双机)
   |
多个后端 (健康检查)

五、常见坑 ⚠️

❌ 只配 HAProxy，不配 Keepalived → 单点
❌ 健康检查路径不存在 → 全被踢
❌ backup 没加 backup 参数
❌ 健康检查太重（压垮后端）

六、你可以告诉我

• 是 HTTP / TCP / gRPC？
• 单机房还是跨机房？
• 用不用容器 / K8s？

我可以直接给你完整可用配置。