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