用 haproxy 做四层负载均衡

发布时间:2025-12-01 06:16

## 场景 应用是 TCP 直连服务：数据库代理、游戏网关、自研长连接服务，这类流量不谈 HTTP 语义，只需要把连接按规则分发到多台后端。haproxy 的四层模式正为此而生，转发开销小，配置直观，健康检查内建，是自建 TCP 分发时最省心的选择之一。相比在应用里自写分发逻辑，把这一层独立出来还有个额外好处：后端的增减、权重的调整对客户端完全透明，扩缩容不用通知任何调用方。 ## 步骤清单 安装后编辑配置，全局段与默认段保持精简，重点是 frontend 与 backend 两段。 ``` frontend ft_main bind *:3307 mode tcp default_backend bk_db backend bk_db mode tcp balance leastconn server db1 10.0.0.11:3306 check inter 2s rise 2 fall 3 server db2 10.0.0.12:3306 check inter 2s rise 2 fall 3 ``` bind 声明监听端口，mode tcp 启用四层转发，balance leastconn 把新连接分给当前连接数最少的后端。check 打开健康检查，inter 是探测间隔，fall 三次失败即摘除，rise 两次成功才恢复，两个阈值都留了缓冲，避免网络抖动引起后端反复进出。 ## 验证 ``` haproxy -c -f /etc/haproxy/haproxy.cfg ``` -c 干跑校验配置语法，通过后再重启服务。功能验证看两处：客户端反复建连，后端各自的连接计数是否均匀增长；手动停掉一台后端，连接是否在数秒内全部落到另一台，恢复后是否重新参与分发。统计页开启后能看到每台后端的会话数、健康状态与转投次数，调参时全靠它，会话分布歪斜说明负载算法与流量形态不匹配，换算法比加后端更先值得尝试。 ## 注意事项 四层转发下后端看到的来源地址是 haproxy 所在机器，需要真实地址的业务要在应用层传递或启用代理协议，并确认后端支持解析。转发长连接服务时留意超时参数，默认值对慢速客户端可能偏短，连接被中段掐断的表现是客户端频繁掉线重连，把空闲超时调到覆盖正常的业务间隔即可。日志里的中断原因字段能区分超时与主动关闭，排这类问题先看日志再动参数。顺云上用两台云服务器跑一主一备的 haproxy 再配虚拟地址漂移，就是一套轻量的入口高可用方案。