Java 关于妈妈和大消息的建议

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

每条消息的有效负载大约为100字节。我预计大约有一半（2500条）的信息会在午夜前后聚集在一起，另一半则会在白天均匀分布。 上面给出的数字都在我预期的高端。（是的，我可能会在不久的将来接受这句话）

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

我的问题是： 这会不会给我带来任何问题，或者通过消息队列发送大量数据完全正常

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

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

或者我应该用另一种方式来处理这个问题，比如说通过jms发送数据的位置，然后让最终接收者在别处拾取数据？ （我希望不会因为耦合、安全问题和额外配置而出现特殊情况）

我对jms的实际细节一无所知，所以如果需要提供更多细节，请告诉我

编辑：

---

我接受了安德烈真正令人敬畏的回答。继续发布建议和意见，我会继续投票给所有有用的东西。

当然，消息大小会影响吞吐量（以毫秒/秒为单位）。消息越大，吞吐量就越小。

消息越大肯定会产生影响，但是您在这里提到的大小（5-50MB）应该可以由任何一台像样的JMS服务器管理

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

---

所以这取决于你的设置。如果5000MB的理论上限对您来说是可管理的（请记住2000MB的32位JVM限制），那么继续吧，但是这种方法显然不能很好地扩展，因此我不建议使用它。如果所有内容都发送到一个持久队列，可能就没问题了，不过我建议先加载一个原型以确保安全。处理可能会很慢，但不一定比通过其他机制获取时慢。无论采用哪种方式，我都绝对建议将较小的消息发送到不同的目的地，以便与较大的消息并行处理。

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

---

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

答案太棒了！较大的消息都是相同的“类型”，并且将被发送到相同的持久队列，因此我对这条消息应该没问题。您最终是如何解决它的？我们对文件系统的物理进行了一些优化，此外，我们还使用了特定于提供商的集群场景，并在4台主机上分发了MessageBroker。