关于 MoM 和大型消息的建议

Question

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

每条消息的有效负载约为 100 个字节。我预计大约一半 (2500) 的消息会在午夜左右聚集，而另一半会在白天稍微均匀分布。 上面给出的数字都在我预期的高端。 （是的，我可能会在不久的将来接受这种说法）。

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

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

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

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

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

我对 jms 的实际细节完全陌生，所以如果我需要提供更多细节，请告诉我。

已编辑： 我接受了安德烈斯真的很棒的答案。继续发布建议和意见，我会继续为所有有用的东西点赞。

Answer 1

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

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

所以这取决于您的设置。如果您可以管理 5000MB 的理论上限（并记住 2000MB 的 32 位 JVM 限制），那么请继续，但是这种方法显然不能很好地扩展，所以我不建议这样做。如果所有内容都发送到一个持久队列，那可能会很好，但是我建议先加载一个原型以确保。处理可能很慢，但不一定比通过其他机制获取的要慢。无论哪种方式，我都绝对建议将较小的消息发送到单独的目的地，在那里它们可以与较大的消息并行处理。

Answer 2

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

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

Answer 3

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