Механизм чтения всех сообщений из очереди за один запрос

Question

Мне нужно решение для следующего сценария, похожего на очередь:

Я хочу писать сообщения в очередь непрерывно.Мое сообщение очень большое, содержит много данных, поэтому я хочу сделать как можно меньше запросов.Так что моя очередь будет содержать много сообщений в какой-то момент.Мой потребитель будет читать из очереди каждые 1 час.(не всякий раз, когда пишется новое сообщение), и оно будет читать все сообщения из очереди.

Проблема в том, что мне нужен способ читать ВСЕ сообщения из очереди, используя только один вызов (я также хочу, чтобы потребитель делал как можно меньше запросов в очередь).

Близким решением будет ActiveMQ, но проблема в том, что вы можете читать только одно сообщение за раз, и мне нужно прочитать их все в одном запросе.

Так что мой вопрос ... Существуют ли другие способы сделать это?это эффективнее?Фактическая вещь, в которой я нуждаюсь, состоит в том, чтобы каким-то образом сохранять сообщения, созданные непрерывно каким-либо приложением, а затем использовать их (а также удалять) одним и тем же приложением одновременно, каждые 1 час.

Причина, по которой я думал, что очередь будет подходящей, заключается в том, что, поскольку сообщения используются, они также удаляются, но мне нужно использовать их все сразу.

Answer 1

Я думаю, что есть некоторые важные вещи, о которых нужно помнить, когда вы ищете решение:

1. Каким образом вам нужно быть «более эффективным» (например, время, денежные затраты,вычислительные ресурсы и т. д.)?
2. Невероятно трудно доказать, что на самом деле не существует других «более эффективных» способов решения конкретной проблемы, поскольку для этого потребуется протестировать все возможные решения.Что вам действительно нужно знать, это, учитывая ваш конкретный вариант использования, какое решение является достаточно хорошим .Это, конечно, требует точного знания того, какой тип производительности вам нужен, и ограничений на получение этих номеров (например, время, денежные затраты, вычислительные ресурсы и т.либо с ActiveMQ 5.x, либо с ActiveMQ Artemis) не совершайте двустороннюю передачу по сети для каждого потребляемого сообщения, поскольку это было бы крайне неэффективно.Скорее, они выбирают блоки сообщений в настраиваемых размерах (например, prefetchSize для ActiveMQ 5.x и consumerWindowSize для ActiveMQ Artemis).Эти сообщения хранятся локально в своего рода буфере и передаются клиентскому приложению, когда соответствующие вызовы API выполняются для получения сообщения.
3. Создание «как можно меньшего количества запросов» редко является способом повышения производительности.Современные брокеры сообщений хорошо справляются с параллельными потребителями.Потребление всех сообщений с одним потребителем резко ограничивает пропускную способность сообщения по сравнению с раскруткой нескольких потоков, каждый из которых имеет своего собственного потребителя.Вместо того, чтобы ограничивать количество запросов потребителей, вы почти наверняка должны максимизировать их, пока не достигнете точки убывающей отдачи.