Канал изменений Azure CosmosDB для сбора документов
Можно ли зарегистрировать службу, работающую на узле кластера, в качестве наблюдателя для передачи изменений для коллекции документов в нескольких учетных записях Cosmos db в кластере?
В случае функции Azure (инициируемой ChangeFeed коллекции документов) эту функцию необходимо подготовить для каждой учетной записи Cosmos db в кластере.
https://docs.microsoft.com/en-us/azure/cosmos-db/change-feed-процессор
https://docs.microsoft.com/en-us/azure/cosmos-db/serverless-computing-database
Как конечная точка API службы может быть активирована библиотекой процессора изменений? Или как служба, работающая на узле кластера, может быть зарегистрирована в качестве наблюдателя для передачи изменений для коллекции документов в нескольких учетных записях Cosmos db в кластере?
Ответы 1
Библиотеку обработчика потока изменений можно использовать в любом консольном/рабочем приложении и запускать на любом хосте, на котором может работать ваше приложение. Примеры доступны в репозитории GitHub https://github.com/Azure/azure-documentdb-changefeedprocessor-dotnet#example.
Ограничение состоит в том, что один наблюдатель может прослушивать одну коллекцию в одном аккаунте. Если у вас несколько учетных записей, каждая коллекция (даже если они имеют одинаковое имя) является отдельной коллекцией и требует отдельного экземпляра работающей библиотеки обработчика канала изменений (коллекции не охватывают несколько учетных записей). Этот экземпляр может находиться в том же вычислительном блоке, что и остальные, и он будет совместно использовать ресурсы (ЦП/ОЗУ) или в независимом.
Они оба действительны. Это зависит от уровня абстракции, который вы предпочитаете. С функциями Azure вы платите за количество выполнений (в плане потребления), и масштабирование может быть выполнено за вас, вы не кодируете наблюдателей, поэтому внедрение зависимостей может быть сложнее, но кодирование в целом намного проще. С библиотекой CFP вам нужен воркер, которому вы платите, независимо от количества изменений, у вас больше контроля над внутренним кодом и вы можете настроить масштабирование по своему вкусу, но вы также несете ответственность за поддержку этих воркеров.
Я пытаюсь использовать библиотеку CFP с зарегистрированным рабочим и наблюдателем. Моя коллекция аренды обновляется всякий раз, когда в отслеживаемой коллекции происходят изменения. Но метод ProcessChangesAsync не вызывается. Я запускаю рабочую службу локально со своей машины.
Убедитесь, что Owner, который появляется в аренде, имеет то же имя, что и имя хоста, которое вы используете в своем воркере. Если нет, это означает, что у вас есть другой запущенный наблюдатель, который прослушивает ту же коллекцию, используя ту же коллекцию аренды. Если вы хотите, чтобы несколько независимых рабочих процессов прослушивали одну и ту же коллекцию и использовали одну и ту же коллекцию аренды, назначьте LeasePrefix для каждой рабочей группы.
Владелец нулевой. У меня есть только один экземпляр рабочего, работающего локально.
Owner = null означает, что никто не получает эту аренду. Ваш рабочий процесс запущен или он запускает процессор (StartAsync) и завершает работу? После StartAsync вы можете заблокировать рабочий процесс и оставить его работающим до тех пор, пока вы не вызовете StopAsync, чтобы завершить его.
Если этого работника необходимо развернуть для нескольких учетных записей Cosmos db, как можно вызвать этот closeAsync для каждого экземпляра службы работника?
Давайте продолжить обсуждение в чате.
Не могли бы вы поделиться дополнительной информацией о том, является ли здесь лучшим вариантом лазурная функция с триггером для коллекции или консольное/рабочее приложение, зарегистрированное в качестве наблюдателя для канала изменений, более предпочтительным вариантом?