Распределенные алгоритмы РИБ 1С

Синхронизация данных между узлами распределённой системы это очень сложная задача. В данной публикации я коснусь следующих проблем:

- идемпотентная обработка сообщений обмена;

- последовательная или причинная согласованность данных;

- обнаружение и разрешение коллизий данных;

- управление асинхронными распределёнными транзакциями;

- защита от сбоев и восстановление работоспособности узлов.

По этому поводу написано много научных трудов. На основании этих трудов были реализованы такие базы данных как Amazon DynamoDB, Apache Cassandra, Riak и другие. Кроме этого были реализованы фреймворки для синхронизации данных как, например, Microsoft Sync Framework.

В данной публикации я главным образом хочу рассказать об алгоритме векторных часов. Немного коснусь проблемы реализации асинхронных распределённых транзакций.

Сразу хочу оговориться, что я не силён в математике, и буду излагать всё своими словами, так как понял сам, что в свою очередь может привести к неточности в научной терминологии. Заранее прошу меня за это извинить.

Логические часы (версия) — простой счётчик на уровне узла, который увеличивается на 1 при каждом выполнении локальной транзакции изменения данных. Счётчик может использоваться на уровне всей базы данных, таблицы, записи или даже поля таблицы. Область применения счётчика называется гранулярностью отслеживания изменений.

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

В планах обмена 1С таким вектором являются номера принятого и отправленного сообщений, а гранулярностью отслеживания изменений — вся база данных узла обмена.

Рассмотрим простое кодирование вектора на следующем примере.

Предположим, что у нас есть три узла A, B и C, которые участвуют в обмене между собой. Объектом синхронизации является документ "Перемещение товаров".

Значение версии для узла A является число 1, для узла B – 3, а для узла C – 5. Предположим, что было решено использовать первый компонент вектора для узла A, второй для узла B, а третий для узла C. Таким образом вектор для данного объекта можно записать так: [1,3,5].

Часто для кодирования вектора используют идентификаторы узлов обмена. Данный вектор можно было бы закодировать, например, в формате JSON таким образом:

[
	{ "A": 1 },
	{ "B": 3 },
	{ "C": 5 }
]

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

[1,0,0] U [1,2,3] = [1,2,3]

    [1,0,0]
    [1,2,3]
-----------
max [1,2,3]

[1,0,0] = [1,0,0] вектора идентичны

[1,0,0] > [2,1,1] последовательность векторов

[1,0,0] | [0,0,1] вектора параллельны

Компоненты вектора: [A,B,C].

Узел B это центральный узел РИБ.

Начальное состояние векторов [0,0,0] – данные отсутствуют.

Все остальные шаги аналогичны.

В конечном итоге данные во всех узлах синхронизированы и имеют один и тот же идентичный вектор [1,0,1].

Компоненты вектора: [A,B,C].

Узел B это центральный узел РИБ.

Начальное состояние векторов [1,0,1].

В данном случае очень важно, чтобы разрешение конфликта в точках синхронизации B2 и C2 было выполнено аналогичным образом и гарантировало получение идентичного результата.

Узел B, кроме всего прочего, отвечает за отправку результата разрешения конфликта в точке B2 в узел A для синхронизации данных в точке A2.

В приведённом ранее примере возможно два результата разрешения конфликта:

1. Побеждает вектор [2,0,1] – данные узла A.

2. Побеждает вектор [1,0,2] – данные узла C.

Типовой механизм РИБ 1С при разрешении конфликтов всегда отдаёт предпочтение центральному узлу. В приведённом ранее примере победила бы версия данных узла A, имеющая вектор [2,0,1].

Другими словами, тот узел, который первым успел бы доставить свои изменения в узел B. Результат такой синхронизации по сути непредсказуем.

Однако не всегда типовой алгоритм разрешения коллизий РИБ 1С является приемлемым. В таком случае необходимо реализовать свою логику разрешения конфликтов.

Предположим, что у нас имеется функция, реализующая алгоритм автоматического разрешения конфликта, отличный от типового алгоритма РИБ 1С. Эта функция применяется во всех узлах для разрешения конфликтов и гарантирует получение идентичного результата.

Из рассмотренного выше примера можно сделать интересный вывод.

Если есть некий объект данных, который может быть изменён в нескольких узлах одновременно, то рано или поздно может возникнуть конфликт параллельного изменения данных. В конечном итоге для обеспечения согласованности данных это должно привести к откату проигравшей локальной транзакции в одном или даже нескольких узлах РИБ.

Таким образом для конкурентных объектов любая локальная транзакция потенциально является распределённой. При этом, учитывая тот факт, что обмен данными выполняется асинхронно при помощи брокера сообщений, такая транзакция является не только распределённой, но и асинхронной.

Для сравнения широко известный протокол двухфазной фиксации 2PC (two-phase commit) по сути является синхронным протоколом, даже не смотря на то, что некоторые его реализации предусматривают сохранение и восстановление состояния распределённой транзакции в случае возникновения технического сбоя. На практике главным недостатком 2PC является низкая производительность, а также всё-таки недостаточная устойчивость к техническим сбоям.

В микросервисной архитектуре для реализации распределённых транзакций широко используется шаблон проектирования "Сага" (Saga pattern). Применение этого шаблона включает в себя реализацию и применение компенсирующих транзакций.

Системы документооборота для обеспечения согласованности данных используют конечные автоматы (state machine) или, проще говоря, состояния документов.

На мой взгляд, в контексте РИБ 1С, использующей в качестве транспорта брокер сообщений, целесообразно говорить о реализации компенсирующих сообщений по аналогии с шаблоном проектирования "Сага".

Типовой механизм РИБ 1С позволяет разрешать коллизии данных в автоматическом режиме, но ценой строгих ограничений. Центральный узел всегда прав. Кто из периферийных узлов первый "достучится" до центрального узла, тот и молодец.

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

По большому счёту платформа 1С имеет все необходимые средства для генерации значений логических часов, создания таблиц для хранения значений векторных часов и различных версий объектов для разрешения коллизий данных.

Применение распределённых алгоритмов в контексте РИБ 1С конечно же возможно, но ... потребует очень больших знаний, умений и трудозатрат. В прочем это касается не только мира 1С =)