上篇回顾
上一篇讲了 ACL 条件路由、会话保持和三层限流架构。这一篇进入一个实战架构模式：用 HAProxy + Keepalived 为多个中间件（MySQL、Redis、Kafka、ES、etcd、MongoDB）提供统一 VIP 入口。
一、问题场景：中间件越来越多
没有统一入口时的困境
MySQL 连 10.0.0.1:3306
Redis 连 10.0.0.2:6379
Kafka 连 10.0.0.3:9092
ES 连 10.0.0.4:9200
etcd 连 10.0.0.5:2379
Mongo 连 10.0.0.6:27017
→ 6 个中间件，6 个 IP，配置复杂
→ 扩容时客户端配置也要改
→ 某个中间件后端扩缩容，所有客户端都要改连接地址统一入口后的架构
所有客户端只管连 VIP:端口
MySQL → VIP:3306
Redis → VIP:6379
Kafka → VIP:9092
ES → VIP:9200
etcd → VIP:2379
Mongo → VIP:27017
后端 IP 变化 → 只改 HAProxy 配置，客户端不改架构图
┌─────────────────────────────────┐
│ VIP: 192.168.1.200 │
│ HAProxy (统一入口) │
├─────────────────────────────────┤
│ :3306 :6379 :9092 :9200 │
│ :2379 :27017 │
└──────┬──────┬──────┬───────────┘
│ │ │
┌────────────┘ │ └──────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ MySQL │ │ Redis │ │ Kafka │
│ 主+从 │ │ 主+从 │ │ 3节点 │
└──────────┘ └──────────┘ └──────────┘二、完整配置示例
全局配置
haproxy
global
daemon
maxconn 4000
user haproxy
group haproxy
defaults
mode tcp
timeout connect 5s
timeout client 30s
timeout server 30s
retries 31. MySQL --- roundrobin + TCP 检查
haproxy
frontend mysql-in
bind *:3306
default_backend mysql-servers
backend mysql-servers
balance roundrobin
option mysql-check user haproxy_check
server mysql1 10.0.0.1:3306 check inter 5s fall 3 rise 2
server mysql2 10.0.0.2:3306 check inter 5s fall 3 rise 2说明 ：MySQL 短连接多，roundrobin 即可；mysql-check 用 MySQL 协议探测，比 TCP 检查更准确。
2. Redis --- first + backup 主从模式
haproxy
frontend redis-in
bind *:6379
default_backend redis-servers
backend redis-servers
balance first
option tcp-check
tcp-check send PING\r\n
tcp-check expect string +PONG
server redis-master 10.0.0.1:6379 check inter 1s
server redis-slave1 10.0.0.2:6379 check inter 1s backup
server redis-slave2 10.0.0.3:6379 check inter 1s backup说明 ：Redis 是主从架构，用 first + backup 确保写请求只到 master；PING/PONG 检查比 TCP 更准确。
3. Kafka --- source 哈希（客户端会话保持）
haproxy
frontend kafka-in
bind *:9092
default_backend kafka-brokers
backend kafka-brokers
balance source
server kafka1 10.0.0.1:9092 check inter 5s
server kafka2 10.0.0.2:9092 check inter 5s
server kafka3 10.0.0.3:9092 check inter 5s说明 ：Kafka 客户端与特定 broker 保持长连接，用 source 哈希保证同一客户端始终连到同一 broker。
4. Elasticsearch --- leastconn + HTTP 健康检查
haproxy
frontend es-in
bind *:9200
mode http
default_backend es-nodes
backend es-nodes
mode http
balance leastconn
option httpchk GET /_cluster/health
http-check expect status 200
server es1 10.0.0.1:9200 check inter 5s
server es2 10.0.0.2:9200 check inter 5s
server es3 10.0.0.3:9200 check inter 5s说明 ：ES 查询请求多、响应时间差异大，leastconn 最优；/_cluster/health 检查集群级别健康。
5. etcd --- roundrobin + HTTP 健康检查
haproxy
frontend etcd-in
bind *:2379
mode http
default_backend etcd-nodes
backend etcd-nodes
mode http
balance roundrobin
option httpchk GET /health
http-check expect string true
server etcd1 10.0.0.1:2379 check inter 5s
server etcd2 10.0.0.2:2379 check inter 5s
server etcd3 10.0.0.3:2379 check inter 5s说明 ：etcd 客户端自带重连和故障转移，roundrobin 即可；/health 返回 {"health":"true"} 表示节点健康。
6. MongoDB --- roundrobin + TCP 检查
haproxy
frontend mongo-in
bind *:27017
default_backend mongo-replicaset
backend mongo-replicaset
balance roundrobin
server mongo1 10.0.0.1:27017 check inter 5s
server mongo2 10.0.0.2:27017 check inter 5s
server mongo3 10.0.0.3:27017 check inter 5s说明：MongoDB 驱动自己做主从切换和读写分离，HAProxy 只做负载均衡。
三、各中间件配置要点速查
| 中间件 | 推荐算法 | 健康检查 | 注意事项 |
|---|---|---|---|
| MySQL | roundrobin | mysql-check 或 TCP | 读写分离需额外方案（如 ProxySQL） |
| Redis | first + backup | tcp-check PING/PONG | 主从架构，写请求只到 master |
| Kafka | source | TCP | 同一客户端保持同一 broker |
| ES | leastconn | HTTP /_cluster/health | 查询多且响应差异大 |
| etcd | roundrobin | HTTP /health | 客户端自带重连，HAProxy 只做负载 |
| MongoDB | roundrobin | TCP | 驱动自己处理主从切换 |
核心原则
- 算法选择看连接特性：短连接 roundrobin → 长连接 leastconn → 状态保持 source
- 健康检查选最准的：有协议层检查就用协议层，没有就用 HTTP，最后才是 TCP
- 每个中间件独立 frontend：同 IP 不同端口，配置隔离，故障互不影响
- 后端扩缩容只改 HAProxy：客户端只管连 VIP:端口，不关心后端 IP 变化
四、架构模式总结
这个"一个 HAProxy 统一多个中间件"的模式，本质上是四层代理的架构抽象：
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 客户端 │ ──→ │ VIP:端口 │ ──→ │ 后端中间件 │
│ (应用) │ │ (HAProxy) │ │ (集群) │
└──────────────┘ └──────────────┘ └──────────────┘
│
解耦了客户端和后端
客户端只认 VIP:端口
后端变化对客户端透明这个模式的好处
- 配置简化：N 个中间件只需要 1 个 VIP，客户端配置量减少 N 倍
- 扩缩容透明：后端节点增减，客户端无需任何变更
- 故障隔离：某个中间件后端故障，HAProxy 自动摘除，不影响其他中间件
- 统一治理：健康检查、限流、日志、监控都在 HAProxy 层统一管理
与 Keepalived 配合
这个配置通常与 Keepalived 配合部署，实现 HAProxy 自身的高可用：
VIP: 192.168.1.200
│
┌─────────────┴─────────────┐
HAProxy A HAProxy B
Keepalived MASTER Keepalived BACKUP下一篇将进入 Keepalived 系列，详细讲解 VRRP 原理、参数调优和生产最佳实践。
本期总结
- 一个 HAProxy 可以为多个中间件提供统一 VIP 入口，每个中间件一个 frontend
- 算法选择：短连接用 roundrobin，长连接用 leastconn，有状态用 source
- 健康检查优先用协议层检查，其次 HTTP，最后 TCP
- 所有中间件共享同一个 VIP，客户端只认
VIP:端口 - 后端扩缩容对客户端透明，只改 HAProxy 配置即可