Конфликты в распределенной системе 1С при обмене данными посредством «Репликации информационных БД»

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

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

- Качество каналов связи между узлами.

Можно привести и другие факторы, которые увеличивают вероятность, но ясно одно – подобные конфликты должны быть зафиксированы и отработаны - не приводить к нарушению целостности данных.

Распределенная система 1С в технологии «Репликация информационных баз данных» выглядит следующим образом:

Рис.1.

    На рисунке 1 (Москва, Казань, Омск, Самара, Чита, Ростов) – это экземпляры БД 1С 7.7, 8.Х, а Дистрибутор – служебная БД, которая выполняет транспортную функцию, функцию фильтрации и разрешения конфликтов.

    В технологии «Репликация информационных баз данных» при возникновении конфликта по данным всегда выигрывает первая поступившая на дистрибутор транзакция. Все остальные проигравшие транзакции будут откатаны. Механизм репликации зафиксирует событие конфликта и, в случае необходимости, оповестит владельца транзакции или ответственного за эти инциденты.

    Почему нельзя проставить узлам распределенной системе приоритеты для принятия решения по выигравшей/проигравшей транзакции, как было в стандартном обмене (выигрывала всегда центральная база данных)?

    На это есть две причины

Решение реализует транзакционную репликацию – последовательную и непрерывную передачу транзакций из одного узла в другой. Стандартный обмен – это решение больше напоминает репликацию слиянием, когда периодически измененные данные мигрируют в другие узлы распределенной системы.
В момент поступления на дистрибутора транзакции есть возможность получить ответ на вопрос «Попала ли транзакция на конфликт в данный момент?», но нет возможности получить ответ на вопрос «Будет ли в будущем транзакция с более высоким приоритетом, которая попадет на конфликт с текущей (до того момента, пока текущая не применилась во всех БД)?».

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