对MoM和大消息的建议

Question

我正在设计一个系统，它将使用jms和一些消息软件（我倾向于ActiveMQ）作为中间件。将有不到100个代理商，每个代理商每天通过队列推送最多5000条消息。

每条消息的有效载荷大约为100字节。我预计大约一半（2500）的信息会在午夜左右聚集，另一半则会在白天有点均匀分布。上面给出的数字都在我期望的更高端。 （是的，我可能会在不久的将来吃这个声明）。

有一种类型的消息，有效载荷将会相当大，比如在5-50mb范围内。 这些消息每天只能从每个代理发送几次。

我的问题是： 这会导致我以任何方式发生问题，还是通过消息队列发送大量数据是完全正常的吗？

例如，在处理较大的消息时，是否会降低吞吐量（较小的消息排队）？

或者消息队列会阻塞较大的消息吗？

或者我应该以不同的方式来解决这个问题，比如说通过jms发送数据的位置，并让最终接收者在其他地方接收数据？ （由于耦合，安全问题和额外配置，我希望没有特殊情况）。

我对jms的实用细节完全陌生，所以只需告诉我是否需要提供更多细节。

编辑： 我接受了Andres真正令人敬畏的答案。继续发布建议和意见，我会保持一切有用的投票。

Answer 1

较大的消息肯定会产生影响，但是您提到的大小（5-50MB）应该由任何体面的JMS服务器管理。

但是，请考虑以下内容。在处理特定消息时，整个消息被读入内存。因此，如果100个代理每个都在大约同一时间或不同时间向另一个队列发送50MB消息，但消息需要很长时间才能出队，那么可能会遇到一种情况，即您试图将5000MB的消息放入内存中。我过去曾遇到类似ActiveMQ带有4MB消息的问题，但是发送的消息比这里提到的数字要多。如果消息都发送到同一个（持久）队列，这应该不成问题，因为只有正在处理的消息需要在内存中。

所以这取决于你的设置。如果5000MB的理论上限对您是可管理的（并且考虑到2000MB的32位JVM限制），那么请继续，但是这种方法显然不能很好地扩展，所以我不会建议它。如果一切都发送到一个持续队列，它可能会很好，但我会建议首先加载一个原型，以确保。处理速度可能会很慢，但不一定比通过其他机制获取速度慢。无论哪种方式，我都会建议将较小的邮件发送到单独的目的地，以便与较大的邮件进行并行处理。

Answer 2

导致消息大小影响吞吐量（单位为秒/秒）。消息越大，吞吐量越小。

Answer 3

我们正在运行一个类似的方案，有更多的消息。我们的做法与Andres的提议类似，对于大量较小的消息使用不同的队列（在我们的场景中仍然约为3-5MB）以及少量大约50-150 MB的消息。

除了已经提到的内存问题之外，在处理大量持久性大消息时，我们还遇到了消息代理的一般性能问题。这是由于需要以某种方式将这些消息存入文件系统，我们遇到了这方面的瓶颈。