Восстановление после сбоя при создании транспортного соединения RabbitMQ с Rebus - PullRequest
Новая
       46

Восстановление после сбоя при создании транспортного соединения RabbitMQ с Rebus

0 голосов
/ 30 января 2019

Мы используем простую настройку, чтобы использовать Rebus для подписки на очередь.Мы должны убедиться, что если очередь RabbitMQ недоступна (например, служба не работает), мы сможем обнаружить это и повторить попытку позже.Нам также нужно учитывать вероятность того, что RabbitMQ выйдет из строя после успешного подключения (возможно, механизм подписки справится с этим?

Вот наш пример настройки; 

var activator = new BuiltinHandlerActivator();

_bus = Configure
    .With(activator)
    .Transport(t => t.UseRabbitMq(configuration["ConnectionStrings:RabbitMQ"], "QueueName"))
    .Routing(r => r.TypeBased().Map<Message>("QueueName"))
    .Options(b => b.SimpleRetryStrategy("QueueName_Error"))
    .Start();

activator.Register(() => messageHandler);
_bus.Subscribe<Message>().Wait();

Обратите внимание, что мы используем ядро ​​.net.

1 Ответ

0 голосов
/ 30 января 2019

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

Можно утверждать, что Rebus должен просто запустить и дождаться успешного установления соединения, а затем выполнить его инициализацию,но это может привести к сокрытию ошибки конфигурации, например, если вы развернете приложение, подключенное к неправильному имени хоста.

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

После запуска Rebus будет поддерживать пул соединений RabbitMQ(IModel s), обнаружение и выбрасывание замкнутых или неисправных соединений.Помимо этого, Rebus использует драйвер RabbitMQ для восстановления после ошибок подключения, поэтому, если вы используете RabbitMQ в режиме высокой доступности , вы можете настроить Rebus с несколькими строками подключения RabbitMQ (разделенными ;),и затем он автоматически переключится на доступный узел, если возникнет ошибка.

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

Единственное, на что нужно обратить внимание, это начальная отправка !То есть, когда вы отправляете первое сообщение (например, из обработчика веб-запроса или где бы то ни было), вы должны быть уверены, что у вас есть альтернативный способ хранения данных сообщения, если Rebus не может подключиться к какому-либоУзлы RabbitMQ вообще.

Если Ребус не может отправить исходное сообщение, вы получите исключение, и тогда вам решать, что с этим делать.Скромное прагматическое решение (по крайней мере, во многих первых версиях систем, вероятно, также во многих производственных системах позже is) - просто записать ошибку в файл вместе с данными, которые вы намеревались отправить в сообщении.

Надеюсь, это разрешит все ваши вопросы ? если нет, пожалуйста, задайте еще.

...