Вирішення конфліктів для двосторонньої синхронізації

Як ви керуєте двосторонньою синхронізацією між "головним" сервером баз даних та багатьма "вторинними" серверами, зокрема вирішенням конфлікту, якщо припустити, що з'єднання не завжди доступне?

Наприклад, у мене є мобільний додаток, який використовує CoreData як "базу даних" в iOS, і я хотів би дозволити користувачам редагувати вміст без підключення до Інтернету. У той же час ця інформація доступна на веб-сайті, до якого підключатимуться пристрої. Що робити, якщо / коли дані на двох серверах БД конфліктують?
(Я називаю CoreData як сервер БД, хоча я знаю, що це дещо інше.)

Чи є якісь загальні стратегії вирішення подібних питань? Ось такі варіанти, про які я можу подумати:
1. Завжди використовуйте дані на стороні клієнта як пріоритетніші
2. Те саме, що і на стороні сервера
3. Спробуйте вирішити конфлікти, позначивши часову позначку редагування кожного поля та прийнявши останню редагування

Хоча я впевнений, що 3-й варіант відкриє місце для деякої руйнівної корупції даних.

Я знаю, що теорема CAP стосується цього, але я хочу лише можливої ​​узгодженості, тому це не виключає повністю, правда?

Пов'язане питання: Найкращі моделі практичної роботи для двосторонньої синхронізації даних . Друга відповідь на це питання говорить про те, що, ймовірно, це зробити неможливо.

Звичайне рішення для того, щоб знати, "яка зміна є правильною", - це векторний годинник . Ви, по суті, відслідковуєте лічильники для кожного сховища, в якому зберігаються дані, і відхиляєте зміни, якщо погляд певного клієнта на стан інших, відрізняється від того, з яким він підключається.

Основне питання, на яке вам доведеться відповісти, - це спосіб вирішення відхилених заощаджень. Це загалом означає деяку операцію злиття.

Зауважте, що векторні годинники не використовують часові позначки в режимі реального часу. Проблеми, пов'язані з синхронізацією годин у режимі реального часу, принаймні такі ж складні, як і синхронізація даних.

Це проблема візантійських генералів , яка нерозв'язна. Ніколи не можна гарантувати синхронізацію двох серверів, якщо ви не можете гарантувати, що через деякий час у вас буде достатня надійна смуга пропускання, щоб виконати синхронізацію за один раз.

Я думаю, що немає стандартного способу зробити це, кожна система використовує власну політику для вирішення конфлікту.

Я зробив кілька моделювання за допомогою двох пристроїв, комп’ютера та телефону та електронної таблиці Google, щоб перевірити, як Google Документи обробляють конфлікти автоматично. Ось деякі випадки:

Випадок 1

1. Комп'ютер і телефон в автономному режимі
2. Комп'ютер редагування комірки зі значенням "комп'ютер", а після редагування комірки зі значенням "телефон"
3. Комп'ютер стає в Інтернеті
4. Телефон стає в Інтернеті, і комп'ютер, і телефон відображає "телефон".

Випадок 2

1. Комп'ютер і телефон в автономному режимі
2. Комп'ютер редагування комірки зі значенням "комп'ютер", а після редагування комірки зі значенням "телефон"
3. Телефон стає в Інтернеті
4. Комп'ютер стає в Інтернеті, і комп'ютер, і телефон відображає "комп'ютер".

Тож принаймні сервер Google Docs використовує останні дані, отримані як більш високі пріоритети, незалежно від того, коли вони були створені (часова мітка клієнта). Я також перевіряв, чи синхронізуються вони у фоновому режимі, і, мабуть, це не відбувається, тому результат вирішення конфлікту є прозорим для користувача.

GIT, з іншого боку, не обробляє конфлікти автоматично, а натомість делегує останньому користувачеві, який намагався змінити сховище, як робити злиття.

Я б зайнявся підходом до Документів Google, якщо це нормально лише синхронізація на передньому плані, коли користувач візуалізує дані. В іншому випадку користувач може бути здивований, що в той час, як його телефон автоматично підключився до WiFi, він не змінює синхронізацію на зустріч, яку він після повторного редагування на своєму ПК вийшов у реальному часі.

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

Я б пішов на підхід GIT в іншому випадку, показавши спливаюче вікно наступного клієнта на передньому плані, попросивши користувача вибрати, яку версію зберегти, або давши можливість відновити злиття.