ActiveMQ：处理缓慢的消费者

Question

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

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

Answer 1

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

首先：我不确定您的确切担忧是什么。 ActiveMQ 确实将消息存储在数据存储中；所有数据都不需要驻留在任何单个位置（代理或客户端）的内存中。所以你实际上应该在这方面做得很好；早期版本确实要求所有 id 都需要放入内存中（不确定是否已解决），但即使是内存使用量也足够低，除非您有数千万条队列中的消息。

关于 ObjectMessage 与 blob；原始字节数组（blob）应该是最紧凑的表示，但由于所有这些都被序列化以进行存储，它只影响客户端的内存使用。预取主要有助于降低访问延迟；但鉴于它们处理速度很慢，您可能不需要任何预取；所以是的，要么将其设置为 1 或 2，要么完全禁用。

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