Первое, что вам нужно решить, это общая политика относительно того, какая сторона считается «авторитетной» в случае противоречивых изменений.
То есть: предположим, что запись № 125 была изменена на сервере 5 января в 22:00, и такая же запись была изменена на одном из телефонов (назовем ее клиентом A) 5 января в 23:00. Последняя синхронизация была 3 января. Затем пользователь снова подключается, скажем, 8 января.
Определить, что нужно изменить, «легко» в том смысле, что и клиент, и сервер знают дату последней синхронизации, поэтому все, что было создано или обновлено (подробнее об этом см. Ниже) с момента последней синхронизации, должно быть согласовано.
Итак, предположим, что единственная измененная запись - № 125. Вы либо решаете, что одна из двух автоматически «побеждает» и перезаписывает другой, либо вам необходимо поддерживать фазу согласования, когда пользователь может решить, какая версия (серверная или клиентская) является правильной, перезаписывая другую.
Это решение чрезвычайно важно, и вы должны взвесить «роль» клиентов. Особенно, если существует потенциальный конфликт не только между клиентом и сервером, но и в случае, если разные клиенты могут изменять одну и ту же запись (записи).
[Предполагая, что № 125 может быть изменен вторым клиентом (клиентом B), есть вероятность, что клиент B, который еще не синхронизировался, предоставит еще одну версию той же записи, что делает предыдущее разрешение конфликта спорным]
Что касается пункта « создано или обновлено » выше ... как вы можете правильно идентифицировать запись, если она была создана на одном из клиентов (при условии, что это имеет смысл в вашей проблемной области)? Предположим, ваше приложение управляет списком деловых контактов. Если клиент A говорит, что вам нужно добавить недавно созданного Джона Смита, а на сервере есть Джон Смит, созданный вчера клиентом D ... создаете ли вы две записи, потому что не можете быть уверены, что они не разные люди? Вы попросите пользователя уладить и этот конфликт?
Есть ли у клиентов «владение» подмножеством данных? Т.е. если клиент B настроен как «авторитет» для данных для области №5, может ли клиент A изменять / создавать записи для области №5 или нет? (Это упростит разрешение некоторых конфликтов, но может оказаться невыполнимым в вашей ситуации).
Подводя итог, можно выделить следующие основные проблемы:
- Как определить "идентичность", учитывая, что отключенные клиенты могли не получить доступ к серверу до создания новой записи.
- Предыдущая ситуация, независимо от того, насколько сложным является решение, может привести к дублированию данных, поэтому вы должны предвидеть, как периодически решать эти проблемы и как информировать клиентов о том, что то, что они считали «записью № 675», действительно было объединено / заменено Запись # 543
- Решите, будут ли конфликты разрешаться указанием (например, «Версия сервера всегда превосходит версию клиента, если первая была обновлена с момента последней синхронизации») или вручную.
- В случае фиата , особенно если вы решите, что клиент имеет приоритет, вы также должны позаботиться о том, как поступать с другими, еще не синхронизированными клиентами, которые могут иметь еще некоторые изменения.
- В предыдущих пунктах не учитывалась детализация ваших данных (чтобы упростить описание). Достаточно сказать, что вместо рассуждений на уровне «записи», как в моем примере, вы можете найти более подходящим записывать изменения на уровне поля. Или работать с набором записей (например, запись человека + запись адреса + запись контактов), одновременно рассматривая их совокупность как своего рода «мета-запись».
Библиография:
Подробнее об этом, конечно же, в Википедии .
Простой алгоритм синхронизации от автора Vdirsyncer
Статья OBJC о синхронизации данных
SyncML®: синхронизация и управление мобильными данными (Книга в O'Reilly Safari)
Бесконфликтные реплицированные типы данных
Оптимистическая репликация ЯСУШИ САЙТО (HP Laboratories) и МАРК ШАПИРО (Microsoft Research Ltd.) - ACM Computing Surveys, Vol. V, № N, 3, 2005.
Александр Трауд, Юрген Наглер-Ихляйн, Франк Каргл и Майкл Вебер. 2008. Циклическая синхронизация данных посредством повторного использования SyncML. В материалах Девятой Международной конференции по управлению мобильными данными (MDM '08). IEEE Computer Society, Вашингтон, округ Колумбия, США, 165–172. DOI = 10.1109 / MDM.2008.10 http://dx.doi.org/10.1109/MDM.2008.10
Лам Ф., Лам Н. и Вонг Р. 2002. Эффективная синхронизация мобильных XML-данных. В материалах одиннадцатой международной конференции по управлению информацией и знаниями (Маклин, Вирджиния, США, 4–9 ноября 2002 г.). ЦИКМ '02. ACM, Нью-Йорк, Нью-Йорк, 153–160. DOI = http://doi.acm.org/10.1145/584792.584820
Cunha, PR и Maibaum, TS 1981. Resource & equil; абстрактный тип данных + синхронизация - Методология программирования, ориентированного на сообщения -. В материалах 5-й международной конференции по разработке программного обеспечения (Сан-Диего, Калифорния, США, 9–12 марта 1981 г.). Международная конференция по программной инженерии. IEEE Press, Пискатауэй, Нью-Джерси, 263-272.
(Последние три взяты из цифровой библиотеки ACM, не знаю, являетесь ли вы ее участником или можете получить их по другим каналам).
С сайта доктора Доббса :
- Создание приложений с помощью SQL Server CE и SQL RDA, Билл Вагнер, 19 мая 2004 г. (Лучшие практики разработки приложений для настольных и мобильных ПК - Windows / .NET)
С arxiv.org:
- Бесконфликтный реплицированный тип данных JSON - в документе описывается реализация JSON CRDT (бесконфликтные реплицированные типы данных - CRDT - это семейство структур данных, которые поддерживают одновременное изменение и гарантируют конвергенцию таких одновременных обновлений).