怎样用HAProxy做高可用

下面从原理 → 常见架构 → 配置示例 → 健康检查 → 故障切换 → 注意事项几个层面，说明如何用 HAProxy 做高可用（HA）。

一、HAProxy 在高可用中的角色

HAProxy 本身不是“自动主备切换”的工具，而是：

• 负载均衡器（LB）
• 反向代理
• 健康检查 & 故障转移的执行者

真正的高可用通常分为两层：

1. HAProxy 自身高可用
2. 后端服务高可用（通过 HAProxy 实现）

二、典型高可用架构

架构 1：HAProxy + Keepalived（最常见）

        VIP (虚拟IP)
          |
    +-----+------+
    |            |
 HAProxy1     HAProxy2
    |            |
 +--+--+      +--+--+
 |App1|      |App2|
 |App2|      |App3|
 +----+      +----+

• Keepalived 提供 VIP
• HAProxy 做 负载均衡 + 健康检查
• 一台 HAProxy 宕机，VIP 漂移到另一台

架构 2：HAProxy + 后端多实例（服务级 HA）

HAProxy
  |
  +-- backend server1
  +-- backend server2
  +-- backend server3

• 某个 backend 挂了
• HAProxy 自动剔除，流量只走健康的节点

三、HAProxy 基础高可用配置示例

1️⃣ 后端服务高可用（核心）

frontend http_front
    bind *:80
    default_backend app_pool

backend app_pool
    balance roundrobin
    option httpchk GET /healthz
    server app1 10.0.0.11:8080 check
    server app2 10.0.0.12:8080 check
    server app3 10.0.0.13:8080 check

✅ 关键点：

• check：启用健康检查
• option httpchk：HTTP 级别探测
• 故障节点自动下线

2️⃣ 高级健康检查（推荐）

backend app_pool
    balance leastconn
    option httpchk GET /healthz
    http-check expect status 200
    server app1 10.0.0.11:8080 check inter 2s fall 3 rise 2

参数说明：

• inter 2s：每 2 秒检查一次
• fall 3：连续 3 次失败判定下线
• rise 2：连续 2 次成功恢复上线

四、HAProxy 自身高可用（Keepalived）

Keepalived 示例（主节点）

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    virtual_ipaddress {
        192.168.1.100
    }
}

备节点

state BACKUP
priority 100

✅ VIP（192.168.1.100）只会出现在一台 HAProxy 上

五、故障切换流程

1. App 节点宕机
   → HAProxy 健康检查失败
   → 自动剔除

2. HAProxy 节点宕机
   → Keepalived 检测不到心跳
   → VIP 漂移
   → 客户端无感知

六、生产环境建议

✅ 必须做的

• 后端服务加 /healthz
• HAProxy 至少 2 台
• 使用 VIP
• 开启 stats 页面监控

⚠️ 注意点

• HAProxy 是单线程模型（1.8+ 支持多线程）
• 不要拿 HAProxy 做数据库主从切换
• TLS 卸载建议放在 HAProxy

七、可扩展方向

• HAProxy + Prometheus + Grafana
• HAProxy + consul（动态服务发现）
• 多 AZ / 多机房容灾

如果你愿意，可以告诉我：

• 是 Web / API / 数据库 / gRPC？
• 用 Docker / K8s / 物理机？
• 想要 单机房还是跨机房 HA？

我可以给你更精确的配置方案。