Spring Websocket使用的RabbitMQ作为Message Broker在负载下死亡

Question

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

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

在我们的应用程序中，每个用户都需要订阅其用户队列/exchange/amq.direct/update以及其他用户可以订阅/topic/someUniqueName的其他队列。

在我们的第一次性能测试中，我们采用了天真的方法，每个用户都订阅了两个新队列。

当大约800个用户同时连接时，运行测试RabbitMQ时会静默死亡，因此大约有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个文件描述符限制。增加它解决了这个问题。