Чтение канала изменений Azure Cosmos DB

  • Статья

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

Вы можете работать с веб-каналом изменений Azure Cosmos DB, используя модель принудительной отправки или модель извлечения. Если используется модель отправки, обработчик канала изменений отправляет операции клиенту, который имеет бизнес-логику для их обработки. Но сложность проверки операций и сохранения состояния для последних обработанных операций обрабатывается на обработчике канала изменений.

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

При чтении из канала изменений Azure Cosmos DB обычно рекомендуется использовать модель принудительной отправки уведомлений, поскольку вам не нужно беспокоиться о следующем:

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

В большинстве сценариев, использующих канал изменений Azure Cosmos DB, используется один из вариантов модели принудительной отправки. Однако существуют сценарии, в которых может потребоваться дополнительный низкоуровневый контроль для модели извлечения данных. К ним относятся следующие объекты.

  • считывание изменений по определенному ключу секции;
  • необходимость в управлении скоростью, с которой клиент получает изменения для обработки;
  • однократный доступ к существующим данным в веб-канале изменений (например, для переноса данных).

Чтение канала изменений с помощью модели принудительной отправки

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

Функции Azure

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

Разработка с помощью Функций Azure имеет простой интерфейс, использовать который может оказаться быстрее, чем развертывать обработчик веб-канала изменений. Триггеры можно создавать с помощью портала Функций Azure или программно с помощью пакетов SDK. Visual Studio и VS Code обеспечивают поддержку для написания Функций Azure. Для кроссплатформенной разработки можно даже использовать CLI Функций Azure. Вы можете написать и отладить код на рабочем столе, а затем развернуть функцию с помощью одной кнопки. Дополнительные сведения см. в статьях Обработка бессерверной базы данных с помощью Функций Azure и Использование канала изменений вместе с Функциями Azure.

Библиотека обработчика веб-канала изменений

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

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

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

Как и в случае с Функциями Azure, разработка с помощью библиотеки обработчика веб-канала изменений очень проста. Однако вы несете ответственность за развертывание одного или нескольких узлов для обработчика канала изменений. Узел — это экземпляр приложения, который использует обработчик канала изменений для прослушивания изменений. Хотя Функции Azure имеет возможности автоматического масштабирования, вы несете ответственность за масштабирование узлов. Дополнительные сведения см. в статье Использование обработчика канала изменений. Библиотека обработчика канала изменений входит в состав Azure Cosmos DB SDK версии 3.

Чтение канала изменений с помощью модели извлечения

Модель извлечения веб-канала изменений позволяет использовать веб-канал изменений в удобном для вас темпе. Изменения должны запрашиваться клиентом, и автоматический опрос изменений не выполняется. Если вы хотите "запомнить" последнее обработанное изменение (аналогично контейнеру аренды модели принудительной отправки), необходимо сохранить маркер продолжения.

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

  • Чтение изменений для всего контейнера.
  • Чтение изменений для определенного диапазона каналов FeedRange.
  • Чтение изменений для определенного значения ключа секции.

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

Нет встроенной гарантии доставки "по крайней мере один раз" с моделью извлечения. Модель извлечения обеспечивает низкоуровневый контроль, позволяя выбрать способ обработки ошибок.

Канал изменений в API-интерфейсах для Cassandra и MongoDB

Функции канала изменений отображаются как потоки изменений в API для MongoDB и запрос с предикатом в API для Cassandra. Дополнительные сведения о реализации API для MongoDB см. в статье Потоки изменений в Azure Cosmos DB для MongoDB.

Собственный Apache Cassandra предоставляет систему отслеживания измененных данных (CDC), механизм для пометки определенных таблиц для архивации и отклонения операций записи в эти таблицы после достижения настраиваемого размера на диске для журнала CDC. Функция канала изменений в Azure Cosmos DB для Apache Cassandra расширяет возможность запрашивать изменения с помощью предиката через CQL. Дополнительные сведения о реализации см. в статье Канал изменений в Azure Cosmos DB для Apache Cassandra.

Дальнейшие действия

Вы можете продолжить знакомство с каналом изменений, перейдя к следующим статьям: