Поддержка RabbitMQ для LIFO или очереди с приоритетом времени

Question

Есть ли способ заставить очередь RabbitMQ вести себя как стек, т.е. клиент получает последнее сообщение, которое было отправлено в очередь (LIFO), а не первое? Или, возможно, в качестве альтернативы сделать ее приоритетной очередью, используя временную метку, которую мог бы установить клиент?

RabbitMQ поддерживает очереди с приоритетами, но его приоритет - это число до 255 (рекомендуется использовать до 10).

Чего я хочу добиться, так это чтобы последние сообщения обрабатывались первыми, поскольку они содержат самую последнюю информацию об источнике. Я все еще хочу обработать старые сообщения, но в ситуациях, когда клиент не может поддерживать (или было некоторое время простоя, и клиент восстанавливается), я сначала хочу обработать самую последнюю информацию о состоянии.

Единственное решение, которое ядо сих пор было предложено использовать TTL для сообщений основной очереди и заставить их перейти в очередь недоставленных сообщений по истечении срока их действия, что также обрабатывается клиентом. Однако это не так чисто, и если для отправки нового обновления статуса источника сообщения требуется больше времени, чем TTL, последнее состояние будет помещено в очередь позади других более старых сообщений с истекшим сроком действия, которые еще предстоит обработать.

Если это невозможно сделать с помощью RabbitMQ, существует ли какая-либо другая рекомендуемая среда обмена сообщениями, которая поддерживает это требование?

Answer 1

Kafka Сжатие журнала было создано именно для описанного вами варианта использования:

Сжатие журнала гарантирует, что Kafka всегда сохранит хотя бы последнее известное значение для каждого ключа сообщения вжурнал данных для одного раздела темы. В нем рассматриваются варианты использования и сценарии, такие как восстановление состояния после сбоев приложения или сбоя системы, или перезагрузка кэшей после перезапуска приложения во время оперативного обслуживания. Давайте более подробно рассмотрим эти варианты использования, а затем опишем, как работает сжатие.

Answer 2

Итак, RabbitMQ - это очередь , а не стек . Он специально разработан для того, чтобы НЕ выполнять то, что вы просите (очередь всегда является структурой данных «первым пришел - первым вышел»).

Однако есть варианты:

1. Предположительно, существует некоторый процесс (например, веб-служба) между клиентом и сервером сообщений. Этот процесс может сохранить данные в дополнительном хранилище (например, memcached ) для немедленного доступа к последнему значению, оставляя очередь без изменений.

2. Вы можетенастроить вторичную комбинацию очередь / сервис. Когда сообщения публикуются, их можно направить в обе очереди. Первая очередь предназначена для интенсивной обработки, а вторая очередь будет службой, единственной задачей которой является обновление последнего значения в memcached или какой-либо другой системе быстрого хранения / поиска. Таким образом, время жизни сообщения в этой очереди, вероятно, будет намного короче.

3. Вы можете реализовать несколько этапов обработки. Первым шагом будет обновление текущего состояния (предположительно, быстрой операции), после чего сообщение затем повторно публикуется в очереди более длинного шага обработки.