HAProxy 通过主从进程模型或软停止信号实现热重载，旧进程处理完现有连接后退出，新进程接管新连接。适用于生产环境配置更新，主要风险在于新配置文件语法错误导致服务无法启动。

命令速用版

以下命令用于检查配置并执行重载，适用于大多数基于 systemd 的 Linux 发行版。

haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl reload haproxy

若未使用 systemd，可通过发送信号实现：

haproxy -f /etc/haproxy/haproxy.cfg -sf $(cat /var/run/haproxy.pid)

为什么会这样

HAProxy 热重载不中断连接的核心在于文件描述符继承与进程信号处理。

当执行重载时，新进程启动并绑定相同端口，旧进程收到 SIGUSR2 信号后进入软停止状态。旧进程不再接受新连接，但继续处理已建立的连接直到关闭。操作系统层面的 socket 文件描述符在进程间传递，确保监听端口不中断。

分步处理

按顺序执行以下步骤可确保重载安全。

步骤 1：检查配置文件语法

在应用更改前，必须验证配置文件合法性，防止新进程启动失败。

haproxy -c -f /etc/haproxy/haproxy.cfg

检查点：输出必须包含“Configuration file is valid”，若有错误需先修复。

步骤 2：执行重载命令

使用系统服务管理命令或手动发送信号。

systemctl reload haproxy

动作：该命令会触发 systemd 调用 HAProxy 的重载逻辑。

步骤 3：监控进程状态

确认新旧进程共存状态。

ps aux | grep haproxy

检查点：应看到多个 haproxy 进程，旧进程 PID 保持不变直到连接耗尽。

怎么验证是否生效

通过连接状态和日志确认重载过程无丢包。

检查监听端口

ss -tnlp | grep haproxy

判断：端口应始终处于 LISTEN 状态，无瞬间消失。

查看错误日志

位置通常在/var/log/haproxy.log 或 journalctl -u haproxy。

判断：重载期间不应出现“Cannot bind socket”或大量连接重置错误。

业务验证

在重载期间发起持续请求，观察是否有 502 或 503 错误。

常见坑

• 配置文件语法错误会导致新进程无法启动，旧进程继续运行但无法更新配置。
• 某些旧版本 HAProxy 不支持主从模式，需确认版本大于 1.8。
• 手动发送信号时 PID 文件路径错误会导致信号发送给错误进程。
• 长连接场景下旧进程可能长时间不退出，需关注内存占用。

常见问题

热重载会断开现有 TCP 连接吗？

不会断开现有连接，旧进程会维持已建立的会话直到客户端或服务端关闭。

配置文件错误会发生什么？

新进程启动失败，旧进程继续提供服务，但配置不会更新，需修复后重新重载。

如何强制结束旧进程？

向旧进程发送 SIGTERM 信号可强制关闭，但会中断该进程处理的剩余连接。