Проблема, с которой вы сталкиваетесь с EasyNetQ/RabbitMQ, заключается в том, что она намного более «сырая» по сравнению с другими службами обмена сообщениями, такими как SQS или Azure Service Bus/Queues, но я сделаю все возможное, чтобы указать вам на правильное направление.
Вопрос 1.
Это будет на вас сделать. Самый простой способ - вы не можете отправить сообщение в RabbitMQ/EasyNetQ, и оно будет помещено во главе очереди для повторной попытки. Это не рекомендуется, потому что он будет почти сразу же повторен (без временной задержки), а также будет блокировать обработку других сообщений (если у вас есть один абонент с номером предварительной выборки 1).
Я видел другие реализации использования «MessageEnvelope». Таким образом, класс-оболочка, который, когда сообщение терпит неудачу, увеличивает значение переменной повтора в MessageEnvelope и возвращает сообщение обратно в очередь. Вы должны сделать это и написать код обертывания вокруг ваших обработчиков сообщений, это не будет функцией EasyNetQ.
Используя вышеизложенное, я также видел, как люди используют конверты, но допускают, чтобы сообщение было мертвым. Когда он находится в очереди с мертвой буквой, в очереди с мертвой буквой появляется другое приложение/работник, читающий элементы.
Все эти подходы выше имеют небольшую проблему, так как на самом деле нет хорошего способа иметь логарифмическую/экспоненциальную/любую возрастающую задержку при обработке сообщения. Вы можете «удерживать» сообщение в коде некоторое время, прежде чем возвращать его в очередь, но это не очень хорошо.
Из всех этих вариантов возможно, что ваше собственное приложение, просматривающее очередь с мертвой буквой, и решение о перенаправлении сообщения на основе конверта, содержащего счетчик повторных попыток, является, пожалуй, лучшим способом.
Вопрос 2.
Вы можете указать мертвый обмен письма по очередям с помощью расширенного API. (https://github.com/EasyNetQ/EasyNetQ/wiki/The-Advanced-API#declaring-queues). Однако это означает, что вам придется использовать расширенный API почти везде, так как использование простой реализации IBus для подписки/публикации ищет очереди, имена которых основаны как на типе сообщения, так и на имени абонента.Использование пользовательского объявления очереди означает, что вы будете обрабатывать наименования своих очередей самостоятельно, а это значит, что когда вы подписываетесь, вам нужно знать имя того, что вы хотите и т. Д. Вам больше не нужно подписываться на авто!
Вопрос 3
сообщение об ошибке Очередь/Dead Letter Queue это просто еще одна очередь. Вы можете слушать эту очередь и делать то, что вам нужно сделать. Но на самом деле не существует какого-либо из готового решения, которое звучит так, как будто оно соответствует вашим потребностям.
Мы обнаружили, что практической пользы для стандартной реализации EasyNetQ не было за пределами одной быстрой демонстрации, привязанной к некоторым общим классам .NET, для пользователей, которые впервые используют их. После этого переключитесь на простое «продвинутое» приложение Easy «API, да, вы можете делать продвинутые вещи, но, честно говоря, это очень простой API для использования. Определенно, поклонник Easy's Advanced API для любой работы. –