Hubble数据库中代理配置 HAProxy
HAProxy 支持优雅停止(graceful stop)和硬停止(hard stop)。
一、硬停止
当向 haproxy 进程发送 SIGTERM 信号时，haproxy 进程会关闭所有已建立的连接并立即退出。硬停止对应于 HAProxy 服务的”stop”和”restart”动作，也对应于启动命令的”-st”选项。
二、软停止
当向 haproxy 进程发送 SIGUSR1 信号时，haproxy 进程会解除绑定监听的套接字，但会在现有连接处理完成后才关闭进程。软停止对应于 HAProxy 服务的”reload”动作，也对应于启动命令的”-sf”选项。该操作会尽量在新进程中无损地(不丢失连接)重新加载新配置信息。
Haproxy reload 在不影响现有连接的情况下，重新加载配置
方式 1
Systemctl reload haproxy
缺点 ：在执行期间会有少量查询任务会失败。
方式 2
graceful restart，即reload。需要使用sf选项指定pid列表 haproxy -f /etc/haproxy/haproxy.cfg [-p /var/run/haproxy.pid] -sf `cat /var/run/haproxy.pid`
-f 指定haproxy 配置文件路径
-p 指定pid列表(默认/var/run/目录下)
-sf :启动后将“完成”信号 （SIGUSR1） 发送到较旧的进程，要求他们完成正在做的事情后并离开。<pid>是要发出信号的 PID 列表（每个参数一个）。列表以任何以“-”开头的选项。如果 pid 列表是空，以便可以根据命令的结果动态构建它比如“pidof”或“pgrep”。当reload的时候，新进程会开启，同时旧进程会在处理完成原来的连接后再停止，在此期间两个进程并存。
注意事项 ：
1.如果提示没有-sf 参数 需要升级 haproxy 版本 推荐版本 2.0.1 或者 1.8 以上版本。
2.在新进程尝试绑定端口时，会有两个几毫秒的窗口期，在高负载情况下可能会有少许连接失败。在此期间新连接的失败率通常在万分之一左右。也就是说在很高的负载下，比如每秒 30000 个新连接的站点，reload 期间可能会出现 3 个失败的连接。
这两个时间窗口如下：
一、新进程绑定不了旧进程已绑定的端口
如果新进程由于旧进程的存在而无法绑定端口，它会经过 SIGTTOU+SIGTTIN 信号序列过程。
当有几十个 frontend，该序列通常持续大约一毫秒，在此期间，某些端口既不会绑定到旧进程，又不会绑定到新进程。
HAProxy 在支持 SO_REUSEPORT 套接字选项的系统上已经解决了这个问题，因为它允许新进程绑定前旧进程不用先解除绑定。大多数 BSD 系统几乎一直支持这一点。Linux 在 2.0 版中支持此功能，并在 2.2 版前后将其删除，不过可以引入一些补丁达到效果。它是在内核 3.9 中重新引入，所以如果观察到的连接失败率高于上述，请确保内核是 3.9 或更新的版本，或者相关补丁已向后移植到内核（可能性不大）。
二、旧进程关闭监听的端口时，套接字的 backlog 中极少数连接无法恢复
当旧进程关闭监听的端口时，内核并不总是能将套接字的 backlog 中挂起的连接恢复。这主要是由于服务器收到客户端的 SYN 后，接下来需要向客户端发送 RST 对连接进行复位造成连接被关闭。
① 在高负载下，套接字在关闭前可能会收到客户端的 SYN 包，服务器需要向客户端发送 RST 包。在一些连少许连接失败都不允许出现的关键环境中，有时会使用防火墙规则来在 reload 期间阻止 SYN 包，从而使客户端重新传输。这完全取决于系统，因为某些系统可能能够访问其他监听队列来避免此 RST。
② 在 socket 关闭前，客户端向处于 SYN_RECV 状态的本地套接字发送了 ACK。这个 ACK 也会导致一个 RST 包，而 haproxy 进程也无法感知到。这种情况更难处理，可以通过在重新启动过程的前一秒左右应用防火墙规则进行过滤。
在生产环境中重新加载配置文件建议此操作在服务负载较低时间进行。
