MoM和大消息的建议

Question

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

每条消息的有效负载大约为100字节。我预计大约一半（2500）的消息会在午夜左右集中出现，另一半则会在白天均匀分布。 上述数字都是我预期的高端范围。 （是的，我可能会在不久的将来吃掉这个陈述）。

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

我的问题是： 这样做会在任何方面给我带来问题，还是通过消息队列发送更大量的数据非常正常？

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

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

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

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

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

- Ronnis

Answer 1

更大的消息肯定会产生影响，但是您提到的大小（5-50MB）应该可以被任何一个像样的JMS服务器处理。然而，请考虑以下情况。在处理特定消息时，整个消息都会被读入内存。因此，如果100个代理同时或在不同时间向不同队列发送50MB的消息，或者消息需要很长时间才能出队列，那么您可能会遇到这样一种情况：您正在尝试将5000MB的消息放入内存中。我曾经遇到过ActiveMQ处理4MB消息时类似的问题，但是发送的消息比这里提到的数字要多得多。如果所有消息都发送到同一个（持久性）队列，则不应该有问题，因为只有正在处理的消息需要在内存中。所以这取决于您的设置。如果5000MB的理论上限对您来说可管理（并记住32位JVM的2000MB限制），那么请继续，但是这种方法显然不能很好地扩展，所以我不建议这样做。如果所有东西都发送到一个持久队列，那么可能没问题，但我建议先进行原型负载测试以确保。处理可能会很慢，但不一定比其他机制获取的速度慢。无论如何，我强烈建议将较小的消息发送到单独的目标，以便可以与较大的消息并行处理。

- Andre van der Schyff

---

太棒了！这些更大的消息都是相同的“类型”，将被发送到相同的持久队列中，所以我在这方面应该没问题。 - Ronnis

Answer 2

我们正在运行一个类似的场景，但消息数量更多。我们采用了Andres提议中的相似方法，使用不同的队列来处理大量较小的消息（在我们的情况下仍然约为3-5MB），以及几个大小在50-150MB左右的大型消息。

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

- roundrobin

---

有趣。你最终是如何解决它的？ - Ronnis

我们对文件系统的物理性能进行了一些优化，并且使用了特定于提供程序的集群方案，在4个主机上分布消息代理。 - roundrobin

Answer 3

当然，消息大小对吞吐量（以每秒消息数计）有影响。消息越大，吞吐量就越小。

- skomp