Configuration HAProxy的热重新配置仍然会导致请求失败，有什么建议吗？

我发现使用这样的命令，当流量很大时，仍然有失败的请求

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

热重新加载更新的配置文件

下面是使用webbench的压力测试结果：

/usr/local/bin/webbench -c 10 -t 30 targetHProxyIP:1080
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET targetHProxyIP:1080
10 clients, running 30 sec.

Speed=70586 pages/min, 13372974 bytes/sec.
**Requests: 35289 susceed, 4 failed.**

我运行命令

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

在压力测试过程中多次

在haproxy文档中，它提到

他们将收到签名 611发出信号，要求他们暂时停止监听端口，以便新端口 612进程可以抓住它们

所以有一段时间旧进程没有监听端口（比如说80），而新进程没有开始监听端口（比如说80），在这个特定的时间段内，它会导致新连接失败，有意义吗

---

那么，是否有任何方法可以使haproxy的配置重新加载不会同时影响现有连接和新连接？

在最近的内核上，最终实现了So_REUSEPORT（3.9+），这个死区不再存在。虽然一个补丁已经为旧内核提供了大约10年，但很明显，许多用户无法修补他们的内核。如果您的系统是较新的，那么新进程将在请求前一个进程释放端口之前成功尝试绑定（），然后有一段时间两个进程都绑定到端口，而不是没有进程

---

连接在关闭时到达离开进程队列的可能性仍然很小。但是，没有可靠的方法可以阻止这种情况发生。

Willy，谢谢你的解释，真的很有帮助。我有一个后续问题：因为在云平台上，路由信息会动态变化，因为它将承载数千个应用程序。一个应用程序的路由更改不能影响其他应用程序，这一点非常重要。当重新配置（比如添加一个新的应用程序）时，是否可以/容易地更改HAProxy代码，而不需要新的流程，只需使用相同的流程来适应更改？是否有一个开发计划，使HAProxy成为一个云平台就绪的负载平衡器（为数千个应用程序提供动态更改路由信息）？我使用最新的3.11内核进行测试，失败的数量没有明显减少，我想知道我是否需要手动启用内核为HAProxy提供的重用端口功能？