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


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

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

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

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

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

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

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

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

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

Использование модели принудительной отправки — это самый простой способ чтения данных из веб-канала изменений. Существует два способа чтения из канала изменений с помощью модели отправки: Функции 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.

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

Поддерживаемые пакеты SDK

.Net V3 Java Node.JS Python

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

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

В Функциях 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.

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

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