HAProxy 的 roundrobin 算法在短连接高并发场景下吞吐量略高，leastconn 算法更适合长连接或后端服务器性能不均的场景。公开资料中没有看到可靠的量化数据表明两者在通用 HTTP 场景下有显著的性能差距，选择应基于业务连接特征而非单纯的性能测试。
先说结论：roundrobin 适合后端配置一致且连接短暂的 HTTP 服务，leastconn 适合数据库代理或长连接服务，两者性能差异取决于连接保持时间而非算法本身绝对速度。
- 适合：roundrobin 用于静态资源或无状态 API，leastconn 用于持久连接或计算密集型后端。
- 重点看：关注后端服务器的连接保持时间和处理能力差异，而非单纯追求算法本身的理论速度。
- 别忽略：leastconn 需要维护连接计数，在高频率新建连接场景下可能增加少量 CPU 开销。
命令速用版
在 HAProxy 配置文件的 backend 段落中，通过 balance 指令切换算法，无需重启即可通过软重载生效。
backend web_servers\n balance roundrobin\n server web1 192.168.1.1:80 check\n server web2 192.168.1.2:80 check
切换为 leastconn 只需修改 balance 参数：
backend web_servers\n balance leastconn\n server web1 192.168.1.1:80 check\n server web2 192.168.1.2:80 check
为什么会这样
roundrobin 算法按顺序分发请求，状态维护开销极低，而 leastconn 算法需要实时统计每个后端的活跃连接数。
roundrobin 不需要记录后端当前负载状态，仅依赖计数器轮转，因此在极高新建连接速率下 CPU 占用略低。leastconn 必须在每次分发时查询并更新连接计数，这引入了锁竞争和内存访问开销，但能避免慢速服务器被过多请求淹没。公开资料中没有看到可靠的量化数据表明在普通 Web 场景下这种开销会导致可感知的延迟差异。
分步处理
第一步：确认业务连接特征，短连接 HTTP 接口优先测试 roundrobin，长连接或数据库代理优先测试 leastconn。
第二步：修改配置文件 balance 指令，执行 haproxy -c -f /etc/haproxy/haproxy.cfg 检查语法。
第三步：执行 systemctl reload haproxy 软重载配置，避免中断现有连接。
第四步：观察后端服务器负载，若发现某台服务器 CPU 或内存显著高于其他，尝试切换为 leastconn。
怎么验证是否生效
启用 HAProxy 内置 Stats 页面，查看各后端服务器的 CurrConn 当前连接数分布。
roundrobin 模式下，各服务器累积连接数应大致相等；leastconn 模式下，空闲服务器的 CurrConn 应始终低于繁忙服务器。
使用命令 echo "show stat" | socat stdio /var/run/haproxy/admin.sock 可快速获取文本格式状态数据。
常见坑
开启 Cookie 会话保持时，负载均衡算法可能失效，因为请求会被强制定向到特定后端。
健康检查失败的后端会被自动剔除，此时算法只在剩余可用服务器间生效，可能导致剩余服务器负载突增。
HTTP Keep-Alive 开启后，连接复用会导致 leastconn 效果不明显，因为新建连接数减少。
常见问题
HAProxy 默认负载均衡算法是什么？
默认算法是 roundrobin，如果在配置文件中未指定 balance 指令，HAProxy 将按轮询方式分发请求。
leastconn 会显著降低吞吐量吗？
公开资料中没有看到可靠的量化数据支持这一说法，但在极高新建连接速率下理论开销略高于 roundrobin。
长连接服务应该选哪种算法？
长连接服务建议选择 leastconn，因为它能将新请求导向当前空闲的服务器，避免单台服务器连接数过多。