我在 Windows 上安装了 RabbitMQ Server 3.6.0（我知道是时候升级了，我已经在其他服务器节点上完成了升级）。
服务器端和客户端均启用心跳（心跳间隔60秒）。
我收到了资源警报（RAM 限制），之后我观察到与 RMQ 服务器的 TCP 连接数量增加。
目前有 18000 个连接，而正常数量为 6000 个。
通过管理插件，我可以看到有很多具有 0 个通道的连接，而我们的“正常”连接至少有 1 个通道。
甚至 RMQ 服务器重新启动也无济于事：所有连接都会重新建立。
1. 这是否意味着他们都真的还活着？
此处描述了类似的问题https://github.com/rabbitmq/rabbitmq-server/issues/384，但正如我所见，它在 v3.6.0 中已完全修复。
2. 我是否理解正确，在 RMQ Server v3.6.0 之前，资源警报后的行为是这样的：每 1 个真实客户端自动恢复连接可能会在服务器端挂起多个 TCP 连接？
也许很重要：我们在服务器和客户端之间有 haProxy。
3. haProxy 可以解释这个额外的连接吗？也许它会阻止客户端接收由于资源警报而关闭连接的信号？
- 他们都还活着吗？
只有你可以回答这个问题，但我想问 - 你怎么会得到成千上万的连接？实际上，您应该只为每个逻辑进程创建一个连接。因此，如果您确实有 6,000 个逻辑进程连接到服务器，这可能是造成如此多连接的原因，但在我看来，即使在这种情况下，您也远远超出了合理的设计限制。
要进行检查，请查看当您终止其中一个逻辑进程时减少了多少连接。
- 我是否理解正确，在 RMQ Server v3.6.0 之前，资源警报后的行为是这样的：每 1 个真实客户端自动恢复连接，多个 TCP 连接可能挂在服务器端？
据我所知，是的。看起来本例中的开发人员遇到了“套接字中的常见问题”，那就是检测断开的连接。如果每次有人误解 TCP 的工作原理我就能得到一美元，我会比贝佐斯有更多的钱。因此，他们发现，当实际需要读取或写入来检测死套接字时，有人做出了一些错误的假设，并且开发人员编写了代码（尝试）来正确处理它。值得注意的是，这看起来并不是一个非常全面的修复，因此如果概念设计问题已被引入到代码的另一部分，那么这个错误可能仍然以某种形式存在。搜索错误报告可能会给您更详细的答案，或者询问支持列表中的某人。
haProxy 可以解释这个额外的连接吗？这要看情况。理论上，haProxy as 只是一个pass-through。为了使代理能够识别连接，必须经过握手，这是一个经过深思熟虑的过程，不可能无意中发生。关闭连接还需要握手，这可能是 haProxy 的罪魁祸首。如果 haProxy 认为连接已断开并在没有该过程的情况下将其丢弃，那么这可能是一个促成原因。但它本身并没有建立这些新的联系。
有时它会出于“临时”目的创建一个单独的简单连接。 重现我的问题的步骤是：
RabbitMQ 中的达到内存警报（例如设置一个容易达到的 RAM 限制并推送大量大消息）。连接将处于状态 “阻塞”。