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