haproxy - 排队+排出请求的正确方法

Question

语境

我正在尝试实现一个实现以下想法的部署脚本：

1. 开始对新传入的请求进行排队，同时等待当前请求完成
2. 等待所有当前请求完成（我认为这叫做“耗尽”）
3. 运行特定于应用程序的部署脚本
4. 处理步骤 (1) 中排队的所有请求，并使 haproxy 恢复正常。haproxy 不应丢弃任何传入连接。如果客户端超时，这是可以接受的。

问题

在此背景下，我可以在 haproxy 文档中找到多种实现此目的的方法：

• set server mybackend/myserver state drain其次是set server mybackend/myserver state ready
• set maxconn frontend myfrontend 0其次是set maxconn frontend myfrontend 1000
• set maxconn backend mybackend/myserver 0其次是set maxconn backend mybackend/myserver 1000

以下哪一种是实现我想要实现的目标的正确方法？

更多背景信息

这可能与https://serverfault.com/a/450983/117598，但以下来自haproxy 文档让我再次确认：

将每个进程的最大并发连接数设置为 。它相当于命令行参数“-n”。达到此限制时，代理将停止接受连接。[...]

对比另一个相互矛盾的片段：

“maxconn”参数指定将发送到该服务器的最大并发连接数。如果传入的并发请求数高于此值，它们将排队，等待释放连接。[...]

Answer 1

将您的设计考虑扩展到网络代理之外。

正如在根据您链接的答案发表博客文章，通常的做法是进行向后兼容的数据转换：

通常，在线进行数据库迁移时，正确的方法涉及多个步骤：

• 以不会破坏现有代码的方式执行模式更改（例如，暂时允许新的非空列为 NULL）。
• 部署可同时适用于新旧模式的代码，并根据新模式填充任何新行。
• 执行数据迁移，正确填充所有旧数据，并正确更新所有约束。
• 部署仅希望看到新模式的代码。

在转换期间，请考虑您的应用程序是否应暂停处理。传入的数据可以存储在队列或数据库中，并在恢复处理后继续工作。

与保持开放网络连接相比，这样做的一个优势是您可以慢慢来。网络超时可能非常短。

Answer 2

我无法使用的haproxy方法，set maxconn frontend myfrontend 0因为当我执行第二个命令来解除对请求的阻止时，set maxconn frontend myfrontend 1000我的系统崩溃了。haproxy

我采用了 OpenResty 的另一种方法，并在此处记录：https://github.com/svilen-ivanov/antract

摘要是一组用 Lua 编写的 OpenResty 脚本，可帮助您对后端服务执行简单的零停机维护。其目标是通过在后端服务因维护而停机并重新启动时将传入请求保持在“飞行状态”来限制对用户的影响。用户会看到一个长请求，一切顺利。