MassTransit, как справиться с падением RabbitMQ

Question

Как правильно настроить MassTransit для обеспечения отказоустойчивости, чтобы справляться с периодически возникающими проблемами с подключением RabbitMQ или с полным отказом RabbitMQ? Я настроил кластер RabbitMQ между двумя разными машинами и настроил HA так, чтобы все отражалось. У меня также есть балансировщик нагрузки F5, настроенный в активном / пассивном режиме, так что весь трафик направляется на первичный узел, но если проверка работоспособности не проходит, он переключается на вторичный узел. Я надеюсь, что любые клиентские соединения после такого аварийного переключения продолжат успешно, но здесь у меня проблемы. Когда я останавливаю RabbitMQ на основном узле, клиентское приложение начинает регистрировать кучу ошибок MassTransit, которые выглядят следующим образом:

RabbitMQ connection failed: Connect failed: myrabbithost.mycompany.com:5671/

Эти ошибки возникают, даже если не происходит никаких действий - нет публикации, Client.Request и т. Д. В конце концов ошибки прекращаются из-за MassTransit, очевидно, отказавшего в соединении, и клиентское приложение падает. Глядя на источник MassTransit, я думаю, что это RabbitMqReceiveTransport.Receive, который генерирует эти ошибки внутри метода RetryUntilCancelled. Похоже, что он использует внутреннюю ConnectionRetryPolicy, так что там можно что-то настроить?

Я создаю экземпляр своего экземпляра шины в Global.asax, запускаю его и храню в памяти, пока работает IIS, и я не знаю, является ли это проблемой или нет; При просмотре документации для MassTransit с использованием контейнера Unity, похоже, что рекомендуется разрешить Unity по умолчанию использовать TransientLifetimeManager, так что экземпляры шины будут сноситься и заново создаваться каждый раз, когда контейнер разрешает его.

Answer 1

Эти клиентские сбои происходили, потому что я использовал Task.Wait() следующим образом:

Task.Run(() => bus.Publish(new TestMessage { Id = num })).Wait();

вместо этого:

Task.Run(() => bus.Publish(new TestMessage { Id = num }));

Без.Wait () клиенты остаются в рабочем состоянии, даже когда RabbitMQ выходит из строя. Теперь проблема в том, что все сообщения, отправленные во время отключения RabbitMQ, но до того, как F5 переключится на вторичный узел, будут потеряны.