Потребитель резервного копирования Rabbit MQ
У меня есть следующий вариант использования, который я пытаюсь настроить в Rabbit MQ:
- Обычно процесс A должен обрабатывать все сообщения, отправленные в очередь A.
- Однако, если процесс A выходит из строя (больше не потребляет данные из очереди A), тогда процесс B должен обрабатывать сообщения, пока процесс A не вернется к работе.
Поначалу кажется, что решением могут быть приоритеты потребителей. https://www.rabbitmq.com/consumer-priority.html. Однако это отправит сообщения процессу B, когда процесс A просто заблокирован для работы с другими сообщениями. Я хочу, чтобы они отправлялись процессу B только тогда, когда процесс A не работает.
Второй вариант может быть мертвым шрифтом. https://www.rabbitmq.com/dlx.html. Если процесс A не читает из очереди A, сообщения в конечном итоге истекают по тайм-ауту, а затем перемещаются в обмен, который пересылает их в очередь, которую читает процесс B. Однако эти параметры требуют ожидания сообщения до истечения времени ожидания, что не идеально. Также сообщение может истечь по таймауту, даже если процесс A все еще работает, что не идеально.
Есть идеи, как можно настроить Rabbit MQ для описанного выше варианта использования? Спасибо
@cdelmas процесс A, вероятно, будет иметь кэшированные данные, которые позволят ему отвечать на сообщения из очереди A значительно (в 100 раз) быстрее, чем процесс B. Процессы идентичны (кроме конфигурации, которая сообщает им, к какой очереди иметь привязку). Клиенты ждут ответа настолько быстро, насколько это желательно.
Хорошо, следующий вопрос: может ли ваш клиент ждать ответа несколько секунд или ему нужны быстрые ответы? Срок действия их запроса ограничен по времени?
Несколько секунд - разумное время ожидания. У запросов нет установленного срока действия.
Ответы 1
Согласно вашим ответам на мои вопросы, я бы, вероятно, использовал приоритет для потребителя, чтобы процесс A обрабатывал максимум сообщений вместе с большим количеством предварительной выборки (если возможно, и вы должны убедиться, что ваш процесс может обрабатывать такое большое количество).
Затем процесс B будет обрабатывать сообщения, которые процесс A не может обработать из-за высокой нагрузки, или все сообщения, когда процесс A недоступен. Вероятно, допустимо, чтобы в случае высокой нагрузки некоторые сообщения обрабатывались с большей задержкой. Не забудьте установить низкий счетчик предварительной выборки для процесса B.
Надеюсь это поможет.
Какой у вас вариант использования? Вычисляют ли процессы A и B разные вещи? Есть ли вариант иметь другой экземпляр процесса A для обработки сообщений? Вам действительно нужно, чтобы все сообщения обрабатывались немедленно (без тайм-аута)?