慢网络中的大RabbitMQ消息

Posted 2021-04-16

我正在使用带有Spring AMQP的RabbitMQ

• 大信息（> 100MB，102400KB）
• 小带宽（<512Kbps）
• 低心跳间隔（10秒）
• 单一经纪人

消耗消息需要> = 200 * 8秒，这超过了我的心跳间隔。来自https://stackoverflow.com/a/42363685/418439

如果节点之间的消息传输时间（60秒？）>节点之间的心跳时间，则会导致集群断开连接并松散消息

1. 即使我使用单一经纪人，我还会面临断线问题吗？
2. 心跳和消费者是否使用相同的线程，如果消费者正在消费，则无法执行心跳？
3. 如果是这样，我可以做什么来消费消息，而不增加心跳间隔或减少我的消息大小？

更新：

在我发布自己的答案后，我收到了另一个答案和评论。感谢您的反馈。只是为了澄清，我不使用AMQP进行文件传输。实际上数据是在JSON消息中，有些是简单而小但有些包含复杂的信息，包括一些免费的手绘。除了在数据中心保存数据外，我们还通过AMQP在分支级别保存消息副本，以防无法连接到数据中心。

答案

所以，这里真正的问题更为基础，那些是：（1）通过AMQP执行大型文件传输是否合适，以及（2）心跳的目的是什么？

心跳

首先，让我们解决心跳问题。作为RabbitMQ文档clearly states，心跳的目的是“确保应用程序层及时发现中断的连接。”

这样做的原因是简单的。在普通的AMQP使用中，在连续消息到达之间可能有几秒甚至几分钟。如果没有通过TCP会话交换数据，许多防火墙和其他网络设备会自动关闭端口以降低企业网络的暴露程度。心跳进一步有助于缓解TCP的基本弱点，这是检测连接断开的难点。网络经历失败，和TCP is not always able to detect that on its own。

因此，这里的底线是，当您传输大型消息时，连接处于活动状态，并且心跳功能没有任何用处，并且可能会给您带来麻烦。在这种情况下最好将其关闭。

移动大文件的AMQP？

第二个问题，我认为更重要的问题是如何处理大文件。为了回答这个问题，我们首先考虑消息队列的作用：发送消息 - 将一些内容与另一个计算机系统进行通信的少量数据。这里的操作词很小。消息通常包含以下三种内容之一：1。命令（执行某些操作），2。事件（发生的事情），3。请求（给我一些数据），以及4.响应（这是您的数据）。关于这些的全面讨论超出了范围，但足以说这些中的每一个通常可以由小于100kB的小消息组成。

实际上，作为RabbitMQ基础的AMQP协议是一个相当繁琐的协议。它需要大的消息是divided into multiple segments of no more than 131kB。这会给大文件传输增加大量开销，尤其是与其他文件传输机制（例如FTP）相比时。其次，消息必须在代理在队列中可用之前由代理完全处理，并且在完成此操作时它会占用代理上的宝贵资源。首先，由于其架构，整个消息必须适合代理的RAM。此解决方案可能适用于一个客户端和一个代理，但在尝试扩展时会快速中断。

最后，在传输文件时通常需要压缩 - HTTP自动支持gzip压缩。 AMQP没有。在面向消息的应用程序中，发送包含指向较大数据文件的资源定位符（例如URL）的消息是很常见的，然后通过适当的方式访问该文件。

这个故事的主旨

正如谚语所说："to the man with a hammer, everything looks like a nail." AMQP不是锤子 - 它是一把精确的手术刀。它具有非常特定的目的，并且在该目的内具有狭窄的适用性。将其用于除预期目的之外的其他目的将导致您正在设计的稳定性和可靠性问题，以及对您的最终产品的总体不满意。

另一答案

1. 即使我使用单一经纪人，我还会面临断线问题吗？

是

2. 心跳和消费者是否使用相同的线程，如果消费者正在消费，则无法执行心跳？

无法确认线程，但是从Java RabbitMQ使用者消费消息时我所观察到的，它不会执行心跳确认。如果消耗时间超过3 x心跳超时计时器（由于大消息和/或低带宽），MQ服务器将关闭AMQP连接。

3. 如果是这样，我可以做什么来消费消息，而不增加心跳间隔或减少我的消息大小？

我通过增加心跳大小来解决我的问题。无需进一步更改代码。