Поделиться через

Разработка устойчивых приложений с помощью пакетов SDK Azure Cosmos DB

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

При создании клиентских приложений, взаимодействующих с Azure Cosmos DB с помощью любого из пакетов SDK, важно понимать несколько основных принципов. Эта статья — руководство по проектированию, помогающее понять эти основные принципы и разрабатывать устойчивые приложения.

Обзор

См. видеообзор основных понятий, обсуждаемых в этой статье:

Режимы подключения

Пакеты SDK Azure Cosmos DB могут подключаться к службе в двух режимах подключения. Пакеты SDK для .NET и Java могут подключаться к службе в режиме шлюза и прямом режиме, а другие пакеты — только в режиме шлюза. В режиме шлюза используется протокол HTTP и режим Direct обычно использует протокол TCP.

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

В целом, для пакетов SDK в режиме шлюза можно ожидать трафик HTTP, а для пакетов SDK в прямом режиме — сочетание трафика HTTP и TCP при различных обстоятельствах (например, при инициализации или получении метаданных либо сведений о маршрутизации).

Экземпляры и подключения клиентов

Независимо от режима подключения, очень важно поддерживать отдельный экземпляр клиента пакета SDK для каждой учетной записи и каждого приложения. Подключения HTTP и TCP ограничиваются экземпляром клиента. Большинство вычислительных сред имеют ограничения по количеству подключений, которые можно открыть одновременно. При достижении этих ограничений затрагивается возможность подключения.

Распределенные приложения и сети

При проектировании распределенных приложений есть три ключевых фактора:

  • ваше приложение и среда, в которой оно выполняется;
  • сеть, которая включает любой компонент между приложением и конечной точкой службы Azure Cosmos DB;
  • конечная точка службы Azure Cosmos DB.

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

Для Azure Cosmos DB предусмотрен полный набор соглашений об уровне обслуживания, но ни одно из них не гарантирует уровень доступности в 100 %. Сетевые компоненты, которые подключаются к конечной точке службы, могут испытывать нерегулярные аппаратные проблемы и терять пакеты. Даже в вычислительной среде, где выполняется приложение, могут возникать пиковые нагрузки ЦП, влияющие на работу. Эти условия могут повлиять на операции пакетов SDK. Обычно при возникновении таких сбоев поступают сообщения об ошибках с определенными кодами.

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

Должно ли приложение выполнять повторные попытки при возникновении ошибок?

Короткий ответ — да. Но не при всех ошибках имеет смысл повторять попытки. Некоторые коды ошибок или состояний не являются временными. В таблице ниже они описаны подробнее:

Код состояния Следует добавить повторную попытку Повторная попытка пакетов SDK Description
400 No No Недопустимый запрос
401 No No Не авторизовано
403 Необязательно No Forbidden
404 No No Ресурс не найден
408 Да Да Истекло время ожидания для запроса
409 No No Сбой по причине конфликта происходит, если удостоверение (идентификатор и ключ секции), предоставленное ресурсу при операции записи, уже занято существующим ресурсом или при нарушении ограничения уникального ключа.
410 Да Да Исключения типа Gone (Исчезновение) (временный сбой, который не должен нарушать гарантии соглашения об уровне обслуживания).
412 No No Сбой предварительного условия происходит, если при операции указано значение eTag, отличное от версии, доступной на сервере. Это ошибка оптимистической блокировки. Повторите запрос после считывания последней версии ресурса и обновления eTag в запросе.
413 No No Размер сущности запроса слишком большой
429 Да Да Выполнение повторной попытки для ошибки 429 безопасно. Ознакомьтесь с руководством по устранению неполадок HTTP 429.
449 Да Да Временная ошибка, которая возникает только при операциях записи и является безопасной для повторных попыток. Это может указывать на проблему проектирования, из-за которой слишком много параллельных операций пытается обновить тот же объект в Azure Cosmos DB.
500 No No Сбой операции из-за непредвиденной ошибки в службе. Обратитесь в поддержку Azure, направив им запрос.
503 Да Да Служба недоступна

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

HTTP 403

Пакеты SDK для Azure Cosmos DB обычно не выполняют повторные попытки при возникновении сбоев HTTP 403. Но есть определенные ошибки, связанные с HTTP 403, на которые приложение может отреагировать. Например, при получении сообщения об ошибке, указывающего на заполнение ключа секции, можно изменить ключ секции документа, который вы пытаетесь записать, на основе какого-либо бизнес-правила.

HTTP 429

Пакеты SDK для Azure Cosmos DB будут по умолчанию выполнять повторные попытки при возникновении ошибок HTTP 429 после настройки клиента и учета заголовка ответа x-ms-retry-after-ms службы. Пакеты будут ожидать, пока пройдет указанное время, прежде чем выполнить повторную попытку.

При превышении количества попыток пакетом SDK в приложении отображается сообщение об ошибке. В идеале можно проверить заголовок x-ms-retry-after-ms в ответе, чтобы получить указание относительно того, как долго следует ожидать перед повторным выполнением запроса. Другая альтернатива — алгоритм экспоненциальной отсрочки или настройка клиента для расширения повторных попыток при возникновении ошибки HTTP 429.

HTTP 449

В большинстве сценариев пакеты SDK для Azure Cosmos DB будут выполнять повторные попытки при возникновении ошибки HTTP 449 с добавочным временем отсрочки в течение фиксированного периода.

При превышении количества автоматических попыток пакетом SDK в приложении отображается сообщение об ошибке. Выполнение повторной попытки для ошибок HTTP 449 безопасно. Из-за высокой степени параллелизма операций записи лучше использовать алгоритм случайной отсрочки, чтобы избежать повторения той же степени параллелизма через фиксированный интервал.

Сбои, связанные с временем ожидания и подключением сети, являются наиболее распространенными ошибками. Пакеты SDK для Azure Cosmos DB являются устойчивыми и будут повторять попытки подключения по протоколам HTTP и TCP, если целесообразна повторная попытка:

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

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

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

В приложениях рекомендуется использовать собственные политики повтора для этих сценариев, а также учитывать, как устранять ошибки, связанные с временем ожидания, при записи. Например, повторная попытка, выполняемая при возникновении ошибки времени ожидания при создании, может привести к ошибке HTTP 409 (конфликт), если предыдущий запрос достиг службы, но его успешное выполнение возможно только при противоположном условии.

Сведения о реализации для конкретных языков

Для получения дополнительных сведений о реализации для конкретных языков см.:

Влияют ли повторные попытки на задержку?

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

Пакеты SDK для Azure Cosmos DB содержат подробные сведения в журналах и данных диагностики, которые помогут определить, какие выполняются повторные попытки. Дополнительные сведения см. в статьях Как выполнить сбор данных диагностики пакета SDK для .NET и Как выполнить сбор данных диагностики пакета SDK для Java.

Как устранить задержку повторных попыток?

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

Однако эта приоритизация также означает, что запросы, которые будут приводить к сбою, всегда будут выполняться в одном конкретном регионе в первую очередь для заданного сценария ошибок. Если отработка отказа в другой регион предпочтительна в этом сценарии, это обычно обрабатывается на уровне инфраструктуры (диспетчер трафика), а не на уровне пакета SDK. Правильная настройка и настройка инфраструктуры могут обеспечить эффективное перенаправление трафика во время региональных сбоев, что позволяет снизить задержку, которая может быть связана с повторными попытками между регионами в сценарии сбоя. Дополнительные сведения о настройке отработки отказа на уровне инфраструктуры см. в Диспетчер трафика Azure документации. Некоторые пакеты SDK поддерживают реализацию аналогичных стратегий отработки отказа непосредственно на уровне пакета SDK. Например, ознакомьтесь с высоким уровнем доступности пакета SDK для Java.

Что можно сказать о региональных сбоях?

Пакеты SDK для Azure Cosmos DB охватывают региональную доступность и могут выполнять повторные попытки в других регионах учетной записи. Статья Сценарии и конфигурации повторных попыток в средах с несколькими регионами поможет понять, какие сценарии охватывают другие регионы.

В каких случаях обращаться в службу поддержки клиентов

Перед обращением в службу поддержки клиентов сделайте следующее:

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

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

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