慢网络中的大RabbitMQ消息

Question

我正在使用带有Spring AMQP的RabbitMQ

• 大邮件（＆gt; 100MB，102400KB）
• 小带宽（<512Kbps）
• 低心跳间隔（10秒）
• 单一经纪人

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

  

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

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

更新：

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

Answer 1

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

<强>心跳

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

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

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

移动大型文件的AMQP？

第二个问题，我认为更重要的问题是，应该如何处理大文件。为了回答这个问题，我们首先考虑消息队列的作用：发送消息 - 将一些内容与另一个计算机系统进行通信的少量数据。这里的操作词是 small 。消息通常包含以下三种内容之一： 1。命令（ go do something ）， 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不是锤子 - 它是一把精确的手术刀。它具有非常特定的目的，并且在该目的内具有狭窄的适用性。将其用于非预期用途的目的，无论您的设计是什么，以及对最终产品的整体不满，都会导致稳定性和可靠性问题。

Answer 2

1. 即使我使用单曲也会遇到断线问题 经纪人？

是

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

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

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

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