有关MoM和大型消息的建议

Question

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

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

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

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

例如，它会在处理较大的消息时减少吞吐量（较小的消息排队）吗？

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

或者我应该以不同的方式处理这个问题，比如通过jms发送数据的位置，让终端接收器在其他地方获取数据？ （由于耦合，安全问题和额外配置，我希望不会出现特殊情况。）

我对jms的实际细节完全不了解，所以请告诉我是否需要提供更多细节。

编辑： 我接受了安德烈斯真正棒极了的答案。继续发布建议和意见，我将继续保持有用的一切。

Answer 1

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

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

所以这取决于你的设置。如果理论上限为5000MB是可以管理的（并考虑到32MB JVM限制为2000MB），那么继续，但这种方法显然不能很好地扩展，所以我不建议。如果所有内容都发送到一个持久队列，它可能会很好，但我建议首先在负载下放置原型以确保。处理可能很慢，但不一定比通过某些其他机制获取的速度慢。无论哪种方式，我肯定会建议将较小的消息发送到不同的目的地，在那里它们可以与较大的消息并行处理。

Answer 2

我们正在使用更多的消息运行类似的场景。我们做了类似于Andres的建议，为大量较小的消息（在我们的场景中仍然是~3-5MB）使用不同的队列，以及几个大约50-150 MB的大消息。

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

Answer 3

因为消息大小对吞吐量有影响（以msgs / sec为单位）。消息越大，吞吐量越小。