我正在设计一个将使用jms和一些消息传递软件(我倾向于ActiveMQ)作为中间件的系统。代理将少于100个，每个代理每天最多通过队列推送5000条消息。
每个消息的有效负载每个大约为100个字节。我预计大约有一半(2500)的消息将在午夜左右聚集，另一半将在白天均匀分布。
上面给出的数字都在我预期的高端。 (是的，我可能会在不久的将来吃掉那句话)。
有一种消息类型，有效负载会大得多，例如在5-50mb范围内。
这些消息每天仅从每个代理发送几次。
我的问题是:
这是否会以任何方式引起我的问题，或者通过消息队列发送大量数据是完全正常的吗？
例如，在处理较大的消息时会降低吞吐量(较小的消息排队)吗？
还是消息队列会阻塞较大的消息？
还是我应该以不同的方式来处理这个问题，比如说通过jms发送数据的位置，然后让最终接收者在其他地方拾取数据？
(由于耦合，安全性问题和额外的配置，我希望没有特殊情况)。
我对jms的实际细节是完全陌生的，所以请告诉我是否需要提供更多细节。
编辑:
我接受了安德烈斯的真棒答案。不断发布建议和意见，我将继续投票支持所有有用的内容。
最佳答案
较大的消息肯定会产生影响，但是您在此处提到的大小(5-50MB)应该可以由任何合适的JMS服务器管理。
但是，请考虑以下内容。在处理特定消息时，整个消息将被读入内存。因此，如果100个代理分别在大约同一时间或在不同的时间将50MB的消息发送到不同的队列，但是消息需要很长时间才能出队，则可能会遇到试图将值(value)5000MB的消息放入内存的情况。过去，使用ActiveMQ遇到4MB消息时遇到了类似的问题，但是发送的消息比此处提到的数字还多。如果所有消息都发送到相同(持久)队列，则应该没有问题，因为只有正在处理的消息需要存储在内存中。
因此，这取决于您的设置。如果理论上可以控制5000MB的上限(并记住32MB的JVM上限2000MB)，那么请继续进行，但是这种方法显然不能很好地扩展，因此我不建议这样做。如果将所有内容发送到一个持久队列中，可能会很好，但是我建议首先将原型(prototype)置于负载下以确保。处理可能会很慢，但不一定比其他某种机制获取的慢。无论哪种方式，我都绝对建议将较小的消息发送到单独的目的地，在这些目的地可以与较大的消息并行处理。
关于java - 有关MoM和大邮件的建议，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4345458/