ActiveMQ: медленные потребители обработки

Question

Относительно ActiveMQ: у меня есть сценарий, когда у меня есть один производитель, который отправляет небольшие (около 10 КБ) файлы потребителям. Хотя файлы небольшие, потребителям требуется около 10 секунд, чтобы проанализировать их и вернуть результат производителю. Я много исследовал, но до сих пор не могу найти ответы на следующие вопросы:

1. Как заставить брокера хранить файлы (полностью) в очереди?
2. Стоит ли использовать ObjectMessage (потому что файлы маленькие) или сообщения BLOB-объектов?
3. Поскольку потребители работают медленно, следует ли мне уменьшить их prefetchLimit или использовать политику рассылки циклическим перебором? Какой из них лучше?
4. И, наконец, в FAQ ActiveMQ я прочитал это: «Если потребитель получает сообщение и не подтверждает его до закрытия, то сообщение будет доставлено другому потребителю». Итак, мой вопрос здесь: гарантирует ли ActiveMQ, что только 1 потребитель будет обрабатывать сообщение (и, следовательно, будет только 1 ответ производителю), или нет? Когда потребитель подтверждает сообщение (в настройках автоматического подтверждения по умолчанию) - при получении сообщения и его сохранении в сеансе или когда заканчивается обработчик onMessage? А также, поскольку потребители настолько медленны в обработке, следует ли мне изменить какое-то «ограничение по времени», чтобы брокер знал, сколько ждать, прежде чем передать работу другому потребителю (это как-то связано с моими предыдущими вопросами)?

Answer 1

Не уверен насчет других, но вот некоторые мысли.

Во-первых: я не уверен, что именно вы беспокоитесь.ActiveMQ хранит сообщения в хранилище данных;все данные не должны храниться в памяти в каком-либо одном месте (брокер или клиент).Таким образом, вы должны быть хороши в этом отношении;более ранние версии требовали, чтобы все идентификаторы помещались в памяти (не уверен, что это было решено), но даже это использование памяти было бы достаточно низким, если бы у вас не было десятков миллионов сообщений в очереди.

Что касаетсяObjectMessage vs blob;Необработанный байтовый массив (blob) должен быть наиболее компактным представлением, но поскольку все они сериализуются для хранения, это влияет только на использование памяти клиентом.Предварительная выборка в основном помогает с задержкой доступа;но, учитывая, что они медленно обрабатываются, вам, вероятно, не нужна предварительная выборка;так что да, либо установите его на 1 или 2, либо полностью отключите.

Что касается гарантий: лучшее, что могут гарантировать распределенные очереди сообщений, - это хотя бы один раз (с возможными дубликатами) или самое большее один раз(без дубликатов, могут потерять сообщения).Обычно лучше взять хотя бы один раз и заставить клиентов к дедупликации, используя предоставленные клиентом идентификаторы.Способ отправки подтверждения зависит от спецификации JMS, поэтому вы можете прочитать больше о JMS;это не относится к ActiveMQ.И да, вы должны установить достаточно большой тайм-аут, чтобы работник обычно мог завершить работу, включая все задержки в сети.Это может замедлить повторную передачу пропущенных сообщений (если сработало, умирает), но, вероятно, это не проблема для вас.