Система, над которой я работаю, имеет несколько сред, каждая из которых работает в отдельных Azure регионах. Наша CosmosDB реплицируется в эти регионы, и запись в нескольких регионах включена . Мы используем модель согласованности по умолчанию (сеанс).
У нас есть azure функций, которые используют триггер CosmosDb, развернутый во всех трех регионах. В настоящее время они используют один и тот же префикс аренды, что означает, что только одна функция обрабатывает изменения в любой момент времени. Я знаю, что мы можем установить для каждого региона разные префиксы аренды, чтобы разрешить параллельную обработку, но я хотел бы укрепить свое понимание, прежде чем делать этот шаг.
Мой вопрос касается поведения потока изменений в отношении репликация в этом сценарии? Согласно этой ссылке https://github.com/MicrosoftDocs/azure-docs/issues/42248#issuecomment -552207409 данные сначала объединяются в основном регионе, а затем обновляется лента изменений.
Другие ресурсы, которые я читал, похоже, предполагают, что каждый регион имеет это собственный канал изменений, который будет обновляться при репликации. Кроме того, в предыдущей ссылке рекомендуется запускать обработчик каналов изменений только в первичном регионе с несколькими ведущими.
В идеальном мире я бы хотел сменить обработчики каналов изменений в каждом регионе, чтобы быстро обрабатывать локальные записи. Эти функции будут обновлять CosmosDB, и я также хочу избежать проблем с репликацией. Мой вопрос - каково фактическое поведение в конфигурации с несколькими ведущими (и, соответственно, правильная архитектура)? . «Безопасно» ли использовать процессоры подачи изменений по регионам, или мы должны использовать один процессор в основном регионе?