ActiveMQ：缓慢处理消费者

Question

关于ActiveMQ：我有一个场景，我有一个生产者向消费者发送小（大约10KB）文件。尽管文件很小，但消费者需要大约10秒钟来分析它们并将结果返回给生产者。我研究了很多，但我仍然无法找到以下问题的答案：

1. 如何让代理（完全）将文件存储在队列中？
2. 我应该使用ObjectMessage（因为文件很小）还是blob消息？
3. 由于消费者处理速度慢，我应该降低prefetchLimit还是使用循环调度策略？哪一个更好？
4. 最后，在ActiveMQ FAQ中，我读到了这一点 - “如果消费者收到消息并且在关闭之前没有确认消息，那么该消息将被重新传送给另一个消费者。”所以我的问题是，ActiveMQ是否保证只有1个消费者会处理消息（因此生产者只有1个答案），或者不是？消费者何时确认消息（在默认情况下，自动确认设置） - 接收消息并将其存储在会话中，或者onMessage处理程序何时完成？而且，由于消费者处理速度太慢，我是否应该更改一些“超时限制”，以便经纪人知道在将工作交给另一个消费者之前要等多少（这与我以前的问题有关）？

Answer 1

不确定其他人，但这里有一些想法。

首先：我不确定你的确切关注点是什么。 ActiveMQ确实将消息存储在数据存储中;所有数据都不需要驻留在任何一个地方（经纪人或客户端）的内存中。所以你应该在这方面做得很好;早期版本确实要求所有ID都需要适合内存（不确定是否已解决），但即使内存使用量足够低，除非您有数千万个队列中的消息。

至于ObjectMessage vs blob;原始字节数组（blob）应该是最紧凑的表示形式，但由于所有这些都被序列化以进行存储，因此它只影响客户端上的内存使用情况。预取主要有助于访问延迟;但鉴于它们处理起来很慢，你可能不需要任何预取;所以是的，要么将其设置为1或2，要么完全禁用。

关于保证：分布式消息队列可以保证的最好是至少一次（可能重复），或者至多一次（没有重复，可能丢失消息）。通常最好至少进行一次，并使用客户提供的ID使客户端进行重复数据删除。如何发送确认是由JMS规范定义的，因此您可以阅读有关JMS的更多信息;这不是ActiveMQ特有的。 是的，您应该将超时设置得足够高，以便工作人员通常可以完成工作，包括所有网络延迟。这可能会减慢已删除邮件的重新传输速度（如果工作已死），但对您来说这可能不是问题。