Лучшая практика для синхронизации общих распределенных данных

В зависимости от того, какую семантику приложения вы хотите предложить пользователям, вы можете выбрать разные решения. Например, если вы на самом деле говорите о пометке объектов, созданных автономным пользователем, с помощью ключевого слова, и хотите поделиться тегами между несколькими объектами, созданными разными пользователями, тогда использование «текста» для тега, как вы предложили, вполне нормально. Как только все изменения будут объединены, теги с одним и тем же «текстом», например, скажем «ЭТО УДИВИТЕЛЬНО», станут общими.

Есть и другие способы обработки отключенных обновлений общих объектов. SVN, CVS и другие системы контроля версий пытаются разрешить конфликты автоматически, а когда не могут, просто сообщают пользователю о конфликте. Вы можете сделать то же самое, просто скажите пользователю, что были одновременные обновления, и пользователи должны обработать разрешение.

В качестве альтернативы, вы также можете регистрировать обновления как единицы изменения и пытаться объединить изменения. Например, если ваш общий объект является холстом, а семантика вашего приложения допускает совместное рисование на том же холсте, то отключенное обновление, которое рисует линию от точки A к точке B, а другое отключенное обновление рисует линию от точки C к точке D, может быть составлен. В этом случае, если вы сохраните эти два обновления как две операции, вы можете заказать два обновления, и при повторном подключении каждый пользователь выгружает все свои отключенные операции и применяет недостающие операции от других пользователей. Возможно, вам понадобится какое-то правило упорядочивания, возможно, основанное на номере версии.

Другая альтернатива: если обновления общих объектов не могут быть согласованы автоматически, и семантика вашего приложения не поддерживает уведомление пользователя и просьбу пользователя разрешить конфликты из-за отключенных обновлений, тогда вы также можете использовать дерево версий для обработки этого. Каждое обновление общего объекта создает новую версию с предыдущей версией в качестве родительской. Когда есть отключенные обновления общего объекта от двух разных пользователей, две отдельные дочерние версии / конечные узлы являются результатом одной и той же родительской версии. Если внутренним представлением состояния вашего приложения является это дерево версий, то внутреннее состояние вашего приложения остается согласованным, несмотря на отключенные обновления, и вы можете обрабатывать две ветви дерева версий каким-либо другим способом (например, сообщая пользователю о ветвях и создавая для них инструменты. для объединения веток, как в системах управления версиями)

Всего несколько вариантов. Надеюсь, это поможет.

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

Всего несколько вариантов. Надеюсь, это поможет.

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

Всего несколько вариантов. Надеюсь, это поможет.

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

Всего несколько вариантов. Надеюсь, это поможет.

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

Всего несколько вариантов. Надеюсь, это поможет.

Ваша проблема очень похожа на системы управления версиями, такие как SVN. Вы можете взять пример из них.

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

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

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

После того, как клиент получит обновленную и объединенную версию данных, вы можете выполнить загрузку.

Будут циклические обходы,

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