MQ Cache? хорошая или плохая идея?

Question

Мне интересно, можно ли MQ использовать в качестве кеша состояния для мониторинга? И это хорошая идея или нет?

В теории у вас может быть много источников (агентов мониторинга), которые обнаруживают проблемные состояния и распределяют их подписчикам через систему MQ, такую ​​как RabbitMQ. Но кто-нибудь слышал об использовании систем MQ для кэширования состояния, поэтому, когда клиенты инициализируются, они читают из очереди состояний перед подпиской на новые сообщения состояния? Это плохой способ использовать MQ?

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

Преимущество было бы децентрализованным уведомлением и теоретически очень полезным, добавляя больше систем mq для ретрансляции событий.

Answer 1

IBM MQ FTE использует такой способ хранения журналов. Я думаю, что это хорошая идея, если вы можете предотвратить переполнение очереди назначения, поскольку IBM MQ, например, удаляет просроченные сообщения только во время вызова GET.

Answer 2

У меня есть прецедент для Rabbit MQ, который содержит последний действительный статус системы. Когда новый клиент этой системы подключается, он получает текущий статус.

Это так просто!

Вы должны использовать последнее значение кэша пользовательского обмена https://github.com/simonmacmullen/rabbitmq-lvc-plugin

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