RabbitMQ - механизм повторного проектирования

Question

Всякий раз, когда я не могу обработать события / сообщения, которые находятся в RabbitMQ, я сохраняю их в MongoDB для автоматической и / или ручной повторной попытки. Вопрос в том, как включить механизм автоматической повторной попытки из MongoDB. Насколько эффективно я могу слушать MongoDB? Хорошо ли хранить сбойные события / сообщения в MongoDB заранее? Или я должен создать очередь ошибок, где я могу прослушивать сбойные события / сообщения и отправлять сообщения в MongoDB для повторной попытки вручную при сбое автоматической повторной попытки? Любые другие предложения?

Мое намерение - разработать эффективный механизм повторных попыток для неудачных событий / сообщений RabbitMQ

Answer 1

Это типичный вариант использования для dead-letter exchanges.

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