Rabbitmq очередь последнего состояния (lvc). Как ее реализовать?

Question

[Alex00qqw]

Есть у нас сервис который следит за местоположением ТС (транспортных средств). Задача оповещать другой сервис через amqp (выбрали rabbit) об изменении состояния ТС (скорость, координаты и тд). Хочется сделать так чтобы в очереди хранилось только последнее состояние. Если получатель по какой-то причине не прочитал предыдущее состояние ТС то сообщение перезатерается. Нашел плагин rabbitmq-lvc-exchange но не могу понять как это работает. Нужно создавать для каждого ТС свою очередь? Например для авто с id 1234567 имя очереди будет vehicle.state.change.1234567. Кто-нибудь подскажет как еще можно реализовать данную задачу именно в rabbit? Просьба не советовать использовать key-value хранилища типа redis. И еще если можно сделать одну очередь для всех ТС подскажите как это реализовать? То есть в если у нас 200 ТС то в очереди может быть максимум 200 сообщений

Answer 1

[Victor Bomberow]

Плагин работает с прямыми привязками, каждому ТС будет соответствовать своя очередь. Поддержание очереди не самая сложная работа для RabbitMQ.

Если вас устраивают ограничены плагина, можете не рассматривать вариант с СУБД. Но если именно через RabbitMQ, то хранить всё в одной очереди идея не лучшая, ибо будете на каждый чих n проверок делать.

С двумя очередями уже поинтереснее, когда первая будет буфером, а вторая - с фактической информацией, но нужно делать свой воркер, который читает из буфера и пишет в очередь, обеспечивая уникальные значения. Очередей две, но нагрузка у вас получится будет на воркере, а не кластере RabbitMQ, а из второй очереди клиенты могут читать и искать сообщение с инфо о своём ТС.
Но фишка RabbitMQ все же в queue/exchanges, делать такое на RabbitMQ не очень хорошо.

Answer 2

[Сергей]

Дополню по плагину, сам не использовал, но по описанию и коду можно сказать как оно работает.
(1) Когда в такой обменник публикуется сообщение:
- Сохраняется связка <routing_key>=<value> [code]
- Дальше маршрутизация происходит так же как и у Direct обменника [code]
(2) Когда к такому обменнику цепляется очередь:
- По ключу связки ищется значение из внутренней базы
- Сообщение с последним значение публикуется в очередь

То есть, если Вам нужно сохранять состояние для N объектов через такой механизм, то для получаения придётся каждый раз делать N биндингов очереди на обменник, затем N раз убирать этот биндинг. А так же не забыть повесить ограничение на длину очереди, так как никому реальные сообщение не требуются.

Как вариант можете форкнуть этот обменник и допилить его так, чтобы при публикации сохранялись только последние состояния (без дальнейшей публикации как Direct), а при подписке на обменник RabbitMQ засылал бы сразу все состояния :-)

Answer 3

[Sergey Shvyrev]

А почему кэш не использовать. Инфиниспан предполагает кластеризацию и подписку на обновления. Подпишетесь на обновления в сервисе и будете получать обновления последнего состояния.
Одна очередь, один биндинг.