作为 Spring Websocket 使用的消息代理的 RabbitMQ 在负载下死亡

Question

我开发了一个应用程序，我们需要处理通过websocket 连接连接到后端的 160k 并发用户。

我们决定使用spring websocket 实现和RabbitMQ 作为消息代理。

在我们的应用程序中，每个用户都需要订阅其用户队列 @9​​87654327@ 以及其他用户也可以订阅 /topic/someUniqueName 的另一个队列。

在我们的第一个性能测试中，我们采用了一种简单的方法，即每个用户订阅两个新队列。

在运行测试时，RabbitMQ 在大约 800 个用户同时连接时静默死亡，因此大约有 1600 个队列处于活动状态 (See the graph of all RabbitMQ objects here)。

我读到了you should be careful opening many connections to RabbitMQ。

现在我想知道approach that is anticipated by Spring Websocket with opening one queue per user 是否是高负载系统的概念问题，或者我的系统是否存在其他错误。

Answer 1

RabbitMQ 的限制因素通常是：

• 内存（可以在仪表板中检查）需要随着消息数量和队列数量（如果您不使用直接进入磁盘的惰性队列）而增长。
• 文件描述符的最大数量（每个连接至少 1 个）在许多发行版中通常默认为太低的值（参考：https://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2012-April/019615.html）
• 用于路由消息的 CPU

Answer 2

我确实找到了问题。我实际上错误地配置了 RabbitMQ 服务，只是给它一个 1024 文件描述符限制。增加它解决了这个问题。