Использование нескольких пространств имен для изоляции приложений от сбоев и аварий служебной шины

Критически важные приложения должны работать постоянно, даже при возникновении незапланированных простоев или аварий. Устойчивость к катастрофическим сбоям ресурсов обработки данных является обязательным требованием для многих предприятий, а в некоторых случаях даже входит в состав отраслевых нормативных положений.

Примечание.

Геоизбыточное восстановление шины Service Bus и георепликация помогают восстановиться после крупномасштабных аварий или навсегда отказаться от неудачного региона Azure, не требуя изменений в конфигурации приложения. Дополнительные сведения об этих функциях и о том, как обеспечить надежность и устойчивость служебной шины Azure, см. в разделе "Надежность" в служебной шине Azure.

Если вы не можете использовать Geo-Disaster recovery или Geo-Replication для удовлетворения ваших требований, можно развернуть несколько пространств имен служебной шины. В этой статье описаны методы, которые можно использовать для защиты приложений от потенциального сбоя службы или аварии с помощью нескольких пространств имен.

Типы репликации

Чтобы обеспечить устойчивость к авариям с помощью 'Стандартного' уровня служебной шины, можно использовать активную или пассивную репликацию. Если очередь или раздел должны оставаться доступными во время сбоя центра обработки данных, создайте одну сущность в обоих пространствах имен. Сущности могут совместно использовать то же имя, так как они существуют в отдельных пространствах имен. Например, можно получить доступ к первичной очереди по адресу contosoPrimary.servicebus.windows.net/myQueue, а к её дополнительному аналогу — по адресу contosoSecondary.servicebus.windows.net/myQueue.

Примечание.

Активная репликация и настройка пассивной репликации являются основными понятиями и не конкретными функциями служебной шины. Логика репликации (отправка в 2 разных пространства имен) находится в приложениях отправителя, а получатель должен иметь пользовательскую логику для обнаружения повторяющихся данных.

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

Активная репликация

При активной репликации для каждой операции используются объекты в обоих пространствах имен. Любой клиент, отправляющий сообщение, отправляет две копии одного и того же сообщения. Первая копия отправляется основной сущности (например, contosoPrimary.servicebus.windows.net/sales), а вторая копия — дополнительной сущности (например, contosoSecondary.servicebus.windows.net/sales).

Клиент получает сообщения из обеих очередей. Получатель обрабатывает первую копию сообщения, а вторая копия пропускается. Во избежание дублирования сообщений отправитель должен помечать каждое сообщение уникальным идентификатором. Обе копии сообщения должны быть помечены одним и тем же идентификатором. Для тега сообщения можно использовать свойства ServiceBusMessage.MessageId или ServiceBusMessage.Subject или пользовательское свойство. Получатель должен поддерживать список сообщений, которые он уже получил.

Примечание.

При активной репликации количество операций удваивается, поэтому этот подход может привести к увеличению расходов.

Пассивная репликация

При отсутствии сбоев в пассивной репликации используется только одна из двух сущностей обмена сообщениями. Клиент отправляет сообщение активной сущности. При сбое операции на активной сущности с кодом ошибки, который указывает, что центр обработки данных, в котором размещена активная сущность, может быть недоступным, клиент отправляет копию сообщения резервной сущности. На этом этапе активные и резервные сущности переключают роли. Отправляя клиент считает старую активную сущность новой сущностью резервного копирования, а старая сущность резервного копирования является новой активной сущностью. Если обе операции отправки завершаются ошибкой, роли двух сущностей остаются неизменными, и возвращается ошибка.

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

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

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

  • Задержка или потеря сообщения. Предположим, что отправитель успешно отправил сообщение m1 в основную очередь, а затем очередь стала недоступной до получения сообщения m1 получателем. Отправитель отправляет следующее сообщение m2 в дополнительную очередь. Если основная очередь временно недоступна, то получатель получит сообщение m1 после того, как очередь снова станет доступной. Когда происходит авария, получатель никогда не получит m1.
  • Дублирование. Предположим, что отправитель отправляет сообщение m в основную очередь. Служебная шина успешно обрабатывает m, но ей не удается отправить ответ. По истечении времени ожидания отправки сообщения отправитель посылает идентичную копию сообщения m в дополнительную очередь. Если получатель смог получить первую копию m до того как основная очередь стала недоступной, то он получит обе копии m приблизительно в одно и то же время. Если получатель не может получить первую копию m до того, как первичная очередь становится недоступной, получатель изначально получает только вторую копию m, но затем получает вторую копию m, когда первичная очередь становится доступной.

В примере задач репликации сообщений Azure с помощью .NET Core демонстрируется репликация сообщений между пространствами имен.

Следующие шаги

Дополнительные сведения об аварийном восстановлении см. в следующих статьях:

  • Last updated on