Продажи: 1-800-867-1389

Асинхронные модели обмена сообщениями и высокий уровень доступности

Обновлено: Сентябрь 2014 г.

Асинхронный обмен сообщениями может быть реализован различными способами. Для очередей, разделов и подписок, которые в совокупности называются сущностями обмена сообщениями, Шина службы Microsoft Azure поддерживает вариант с механизмом хранения и переадресации. В обычной (синхронной) модели сообщения отправляются в очереди и принимаются из очередей и подписок. Ваши приложения зависят от постоянной доступности этих сущностей. При изменения работоспособности объекта из-за различных обстоятельств потребуется сущность с меньшей емкостью, которая может удовлетворить большинство потребностей.

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

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

  1. Не удается отправить сообщения.

  2. Не удается получить сообщения.

  3. Не удается управлять сущностями (создать, восстановить, изменить или удалить сущность).

  4. Не удается связаться со службой.

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

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

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

  • Проблема в системе, от которой зависит Служебная шина. Например, в части хранилища могут возникнуть проблемы.

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

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

noteПримечание
Термин хранилище может означать как хранилище Azure, так и SQL Azure.

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

В Служебная шина регулирование позволяет управлять скоростью обмена сообщениями. Каждый отдельный узел Служебная шина хранит множество сущностей. Каждая из этих сущностей предъявляет требования к системе с точки зрения ЦП, памяти, хранилища и других аспектов. Если обнаруживается, что загрузка по данным направлениям превышает определенные пороговые значения, Служебная шина может отказать в обработке запроса. Вызывающая сторона получает ServerBusyException и повторяет попытку через 10 секунд.

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

Другие компоненты в Azure могут иногда сталкиваться с проблемами службы. Например, если система, которую использует Служебная шина, обновляется, эта система может временно сократить свою рабочую емкость. Чтобы обойти эти проблемы, Служебная шина регулярно исследует причины и применяет исправления. Эти исправления имеют ряд побочных эффектов. Например, для обработки временных проблем с хранилищем Служебная шина реализует систему, которая позволяет согласованно отправлять сообщения. Из-за характера исправления на появление отправленного сообщения в соответствующей очереди или подписке может потребоваться до 15 минут, после чего оно станет готово к приему. Вообще говоря, большинство сущностей не будет сталкиваться с этой проблемой. Тем не менее, учитывая количество сущностей в Служебная шина в Azure, это исправление иногда требуется для небольшого подмножества клиентов Служебная шина.

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

В этих случаях клиентское приложение формирует исключение TimeoutException или MessagingException. В Служебная шина .NET SDK содержится исправление для этой проблемы в форме автоматизированной логики повтора на стороне клиента. Если период повторения исчерпан, но сообщение не доставлено, можно воспользоваться другими возможностями, например сопряженными пространствами имен. Сопряженные пространства имен имеют другие особенности, которые рассматриваются далее в этом документе.

Наиболее вероятная причина сбоев в центре обработки данных Azure — сбой при развертывании обновления для Служебная шина или зависимой системы. По мере взросления платформы вероятность этого типа ошибок снизилась. Сбой центра обработки данных также может произойти по следующим причинам:

  • Отключение электричества.

  • Подключение (разрыв интернет-связи между клиентами и Azure).

В обоих случаях проблему вызывает естественная или техногенная катастрофа. Чтобы обойти эту проблему и гарантировать, что вы можете отправлять сообщения, можно использовать сопряженные пространства имен, чтобы обеспечить отправку сообщений через второе расположение, пока основное расположение не станет работоспособным.

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

  • Основное пространство имен. Пространство имен, с которым ваше приложение взаимодействует в ходе операций отправки и получения.

  • Дополнительное пространство имен. Пространство имен, которое используется в качестве резервного по отношению к основному. Логика приложения не взаимодействует с этим пространством имен.

  • Интервал отработки отказа. Продолжительность приема обычных ошибок перед тем, как приложение выполнит переключение с основного пространства имен на дополнительное.

Сопряженные пространства имен поддерживают доступность отправки. Доступность отправки фокусируется на сохранении возможности отправлять сообщения. Чтобы использовать доступность отправки, приложения должны отвечать следующим требованиям:

  1. Сообщения принимаются только от основного пространства имен.

  2. Сообщения, отправленные в выбранные очереди или разделы, могут приходить в неправильном порядке.

  3. Если ваше приложение использует сеансы:

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

    2. Состояние сеанса поддерживается только в основном пространстве имен.

  4. Основная очередь может восстановиться и начать прием сообщений до того, как дополнительная очередь доставит все сообщения в основную очередь.

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

Сопряженные пространства имен поддерживают следующий новый метод в классе MessagingFactory:

public Task PairNamespaceAsync(PairedNamespaceOptions options)

Когда задача завершается, сопряжение пространств имен также завершено, и они готовы к обработке любых MessageReceiver, QueueClient или TopicClient, созданных в MessagingFactory. PairedNamespaceOptions — это базовый класс для различных типов сопряжения, доступных в MessagingFactory. В настоящее время единственный производный класс — это SendAvailabilityPairedNamespaceOptions, который реализует требования к доступности отправки. SendAvailabilityPairedNamespaceOptions имеет набор конструкторов, основанных друг на друге. Глядя на конструктор с наибольшим числом параметров, можно понять поведение других конструкторов.

public SendAvailabilityPairedNamespaceOptions(
    NamespaceManager secondaryNamespaceManager,
    MessagingFactory messagingFactory,
    int backlogQueueCount,
    TimeSpan failoverInterval,
    bool enableSyphon)

Смысл этих параметров таков:

  • secondaryNamespaceManager: инициализированный экземпляр NamespaceManager для дополнительного пространства имен, которое метод PairNamespaceAsync может использовать для настройки дополнительного пространства имен. Для получения списка очередей в пространстве имен будет использован диспетчер, который проверит, что необходимые очереди необработанных сообщений существуют. Если этих очередей не существует, они будут созданы. Для NamespaceManager требуется возможность создавать токены с утверждением Manage.

  • messagingFactory: экземпляр MessagingFactory для дополнительного пространства имен. MessagingFactory используется для отправки и, если свойство EnableSyphon равно true, получения сообщений из очередей необработанных сообщений.

  • backlogQueueCount: число создаваемых очередей необработанных сообщений. Это значение должно быть не меньше 1. При отправке необработанных сообщений конкретная очередь будет выбрана случайным образом. Если вы установите значение равным 1, то можно будет использовать только одну очередь. Когда это происходит, и в единственной очереди возникают ошибки, клиент не сможет попытаться использовать другую очередь, и сообщение не будет отправлено. Рекомендуется задать более высокое значение, значение по умолчанию — 10. Вы можете изменить это значение на более высокое или низкое в зависимости от объема данных, которое приложение отправляет за день. Каждая очередь необработанных сообщений может хранить до 5 ГБ сообщений.

  • failoverInterval: период времени, в течение которого будут приниматься сбои основного пространства имен перед переключением отдельных сущностей на дополнительное пространство имен. Отработки отказа производятся для отдельных сущностей. Сущности в одном пространстве имен часто находятся на разных узлах в Служебная шина. Сбой в одной сущности не подразумевает сбой в другой. Вы можете установить это значение как System.TimeSpan.Zero для аварийного переключения на дополнительное пространство имен сразу после первого серьезного сбоя. Сбои, запускающие таймер обработки отказов, — это любые MessagingException, в которых свойство IsTransient равно false, или TimeoutException. Другие исключения, например UnauthorizedAccessException, не смогут вызвать отработку отказа, поскольку они свидетельствуют о том, что клиент настроен неправильно. ServerBusyException не может вызвать отработку, поскольку правильный шаблон — ожидание в течение 10 секунд с повторной отправкой сообщения.

  • enableSyphon: указывает на то, что данное сопряжение также должно передавать сообщения из дополнительного пространства имен обратно в основное пространство имен. В целом приложения, отправляющие сообщения, должны задавать здесь значение false; приложения, получающие сообщения, должны использовать значение true. Причина заключается в том, что часто количество получателей сообщений меньше числа отправителей сообщений. В зависимости от количества получателей можно сделать так, чтобы один экземпляр приложения отвечал за эту передачу. Использование нескольких получателей имеет финансовые последствия для каждой очереди необработанных сообщений.

Чтобы использовать этот код, создайте основной экземпляр MessagingFactory, дополнительный экземпляр MessagingFactory, дополнительный экземпляр NamespaceManager и экземпляр SendAvailabilityPairedNamespaceOptions. Вызов может быть простым, как показано далее:

SendAvailabilityPairedNamespaceOptions sendAvailabilityOptions =
    new SendAvailabilityPairedNamespaceOptions(secondaryNamespaceManager, secondary);
primary.PairNamespaceAsync(sendAvailabilityOptions).Wait();

При завершении задачи, возвращенной методом PairNamespaceAsync, все будет настроено и готово к использованию. До возврата задачи вы могли не завершить все фоновые действия, необходимые для работы сопряжения. В результате не следует начинать отправку сообщений, пока задача не выполнит возврат. Если произошли какие-либо ошибки, например обнаружились неправильные учетные данные, или не удалось создать очереди необработанных сообщений, соответствующие исключения будут создаваться после выполнения задачи. После возврата из задачи убедитесь, что очереди были найдены или созданы, проверив свойство BacklogQueueCount своего экземпляра SendAvailabilityPairedNamespaceOptions. Для приведенного выше кода эта операция выглядит следующим образом:

if (sendAvailabilityOptions.BacklogQueueCount < 1)
{
    // Handle case where no queues were created. 
}

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв
Показ:
© 2014 Microsoft