Каналы изменений Cosmos DB в кластере Kubernetes с произвольным количеством модулей

У меня есть коллекция в моей базе данных Cosmos, в которой я хотел бы наблюдать за изменениями. У меня есть много документов (официальных и неофициальных), объясняющих, как это сделать. Однако есть одна вещь, которую я не могу заставить работать надежным образом: как мне получить одни и те же изменения в нескольких экземплярах, если у меня нет общей ссылки на имена экземпляров?

Что я имею в виду? Что ж, я выполняю свои рабочие нагрузки в кластере Kubernetes (AKS). У меня есть переменное количество экземпляров в кластере, которые должны наблюдать за моей коллекцией. Чтобы каналы изменений работали правильно, у меня должно быть уникальное имя экземпляра для каждого экземпляра. Единственный кандидат, который у меня есть, - это название стручка. Обычно это форма <deployment-name>-<random string>. Например. pod-5f597c9c56-lxw5b.

Если я использую имя модуля в качестве имени экземпляра, все экземпляры не получат одинаковые изменения (что является моим требованием), только один экземпляр получит изменение (см. https://docs.microsoft.com/en-us/azure/cosmos-db/change-feed-processor#dynamic-scaling). Что я могу сделать, так это использовать вместо этого имя модуля в качестве имени канала, тогда все экземпляры получат одинаковые изменения. Это то, что, я боюсь, в какой-то момент укусит меня за задницу; заглянув в контейнер аренды, я вижу набор документов для каждого имени канала. Поскольку имена модулей приходят и уходят (случайная строковая часть имени), я боюсь, что контейнер со временем будет расти, создавая кучу мусора. Я знаю, что Cosmos может справиться с огромными рабочими нагрузками, но, знаете, мне нравится держать все в порядке.

Как я могу содержать эту вещь в чистоте и порядке? Я действительно не хочу изобретать (или повторно использовать в этом отношении!) Какой-то протокол между моими экземплярами, чтобы голосовать за то, какой экземпляр получит какое имя из конечного набора имен.

Одним из простых решений было бы создать собственные имена экземпляров, если бы AKS или Kubernetes содержали какой-то индекс для моих модулей. Я знаю, что наборы с отслеживанием состояния дают мне это, но я не хочу использовать наборы с отслеживанием состояния, поскольку сами поды на самом деле не имеют состояния (за исключением этого конкретного аспекта!).


person Jörgen Sigvardsson    schedule 25.06.2020    source источник
comment
Думаю, я мог бы найти обходной путь. Вопрос вращается вокруг обработчика каналов изменений в Cosmos SDK. Я нашел итераторы каналов и думаю, что смогу реализовать их с помощью своего собственного решения.   -  person Jörgen Sigvardsson    schedule 25.06.2020


Ответы (2)


Появилась новая модель получения изменений канала (которая находится в предварительном просмотре в это время).

Отличия заключаются в следующем:

изменить модель подачи канала по сравнению с обработчиком изменения канала

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

person Matias Quaranta    schedule 26.06.2020
comment
Да, я нашел модель итератора / вытягивания, но, к сожалению, она находится в предварительной версии. Я немного опасаюсь использовать зависимости предварительного просмотра в среде массового производства. Я (на данный момент) решил это, используя несколько каналов, и при выключении я удаляю <feedname>* в контейнере аренды. Как только модель вытягивания выйдет из предварительного просмотра, я воспользуюсь ею. - person Jörgen Sigvardsson; 27.06.2020
comment
Я вижу, что вы работаете в команде разработчиков Cosmos (или, по крайней мере, вы внесли свой вклад, судя по PR-дискуссиям). Есть ли у вас какие-нибудь подробности о том, когда функция выйдет из предварительной версии? - person Jörgen Sigvardsson; 29.06.2020
comment
У нас пока нет официальной даты GA, так как мы все еще собираем отзывы, чтобы определить окончательный API. Функциональность не должна измениться, но поверхность API (параметры или имена методов) может (или нет, в зависимости от обратной связи) немного измениться. - person Matias Quaranta; 29.06.2020

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

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

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

person bpdohall    schedule 25.06.2020