关于MoM和大型消息的建议

Question

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

每个消息的有效负载约为100个字节。我预计大约一半(2500条)的消息会在午夜左右聚集，而另一半则会在白天平均分布。上述数字均在我预期的较高水平。(是的，我可能会在不久的将来吃下那份声明)。

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

我的问题是：会以任何方式给我带来问题吗?或者通过消息队列发送更多的数据是完全正常的吗？

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

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

或者我应该以一种不同的方式来处理这个问题，比如通过jms发送数据的位置，然后让终端接收者将数据收集到其他地方？(由于耦合、安全问题和额外的配置，我希望没有特例)。

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

编辑：，我接受了安德烈斯最棒的答案。继续张贴建议和意见，我会不断更新所有有用的东西。

Answer 1

更大的消息肯定会产生影响，但是这里提到的大小(5-50MB)应该可以由任何合适的JMS服务器来管理。

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

这取决于你的设置。如果理论上5000‘t的上限对您来说是可管理的(并且要记住2000’t的32位JVM限制)，那么继续前进，但是这种方法显然不能很好地扩展，所以我不会建议它。如果所有的东西都被发送到一个持久队列中，它可能会很好，但是我建议首先加载一个原型来确保。处理可能比较慢，但不一定比其他机制获取的要慢。无论哪种方式，我都建议将较小的消息发送到不同的目的地，在那里它们可以与较大的消息并行处理。

Answer 2

我们正在运行一个类似的场景，其中包含更多的消息。我们这样做类似于Andres的建议，使用不同的队列来处理大量较小的消息(在我们的场景中仍然是3到5MB)，而很少的大消息大约在50-150 MB之间。

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

Answer 3

当然，消息大小会影响吞吐量(以msgs/秒为单位)。消息越大，吞吐量就越小。