Каковы распространенные ошибки синхронизации на основе меток времени?

Question

Я реализую свой первый код синхронизации.В моем случае у меня будет 2 типа клиентов iOS для каждого пользователя, которые будут синхронизировать записи с сервером, используя lastSyncTimestamp, 64-битное целое число, представляющее эпоху Unix в миллисекундах последней синхронизации.Записи могут быть созданы на сервере или клиентах в любое время, и записи обмениваются как JSON по HTTP.

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

Iзнать, что git и некоторые другие системы управления версиями избегают синхронизации с метками времени для подхода синхронизации согласования на основе контента.Я мог бы представить такой подход и для моих приложений, где при использовании uuid или hash объектов оба партнера объявляют, какие объекты принадлежат им, а затем обмениваются ими, пока оба узла не имеют одинаковые наборы.

Если кто-нибудь знает какие-либо преимущества или недостатки синхронизации на основе содержимого по сравнению с синхронизацией на основе меток времени в целом, это также будет полезно.

Редактирование - Вот некоторые преимущества / недостатки, которыеЯ придумал для синхронизации времени и контента на основе.Пожалуйста, оспорить / исправить.

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

• Джонни - «Я получил эту карточку».
• Дэйви - «Я получил эту карточку. Дайте мне эту карту».
• Джонни - «Здесьэто ваша карточка. Дай мне эту карточку. "
• Дэйви -" Вот твоя куча карточек ".
• ....
• Оба -" Мы закончили"

Преимущества синхронизации по меткам времени

• Простота реализации
• Одно свойство, используемое для синхронизации.

Недостатки синхронизации по меткам времени

• Время - это относительное понятие для наблюдателя, и часы разных машин могут быть не синхронизированы.Есть несколько способов решить эту проблему.Генерируйте временную метку на одной машине, которая плохо масштабируется и представляет единственную точку отказа.Или используйте логические часы, такие как векторные часы.Для обычного разработчика, строящего свою собственную систему, векторные часы могут быть слишком сложными для реализации.
• Синхронизация на основе меток времени работает для синхронизации клиента с мастером, но не работает так же хорошо для синхронизации между равноправными узлами или там, где может произойти синхронизацияс двумя мастерами.
• Одна точка отказа, независимо от того, что генерирует метку времени.
• Время на самом деле не связано с содержимым синхронизируемой информации.

Преимущества основанной на контенте синхронизации

• Нет необходимости поддерживать временную метку для одного участника.2 одноранговых узла могут начать сеанс синхронизации и начать синхронизацию на основе содержимого.
• Четко определенная конечная точка для синхронизации - когда обе стороны имеют идентичные наборы.
• Позволяет одноранговой архитектуре, где любой одноранговый узелможет выступать в роли клиента или сервера при условии, что они могут размещать HTTP-сервер.
• Синхронизация работает с содержимым наборов, а не с абстрактным понятием времени.
• Поскольку синхронизация строится вокруг контента,Синхронизация может быть использована для проверки содержимого, если это необходимо.Например, хэш SHA-1 может быть вычислен для содержимого и использован как uuid.Это можно сравнить с тем, что отправляется во время синхронизации.
• Более того, хэши SHA-1 могут основываться на предыдущих хешах для поддержания согласованной истории контента.

Недостатки синхронизации на основе контента

• Для реализации могут потребоваться дополнительные свойства ваших объектов.
• Больше логики с обеих сторон по сравнению с синхронизацией на основе меток времени.
• Чуть более болтливый протокол (это можно настроить, синхронизируя контент в кластерах).

Answer 1

Часть проблемы в том, что время не является абсолютной концепцией. То, происходит ли что-то до или после чего-то другого, является вопросом перспективы, а не соответствия настенным часам.

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

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

Answer 2

Я не знаю, применимо ли это в вашей среде, но вы могли бы подумать, чье время «правильное», клиент или сервер (или если это вообще имеет значение)? Если все клиенты и все серверы не синхронизированы с одним и тем же источником времени, может существовать небольшая вероятность того, что клиент получит неожиданный результат при синхронизации (или с) сервера с использованием времени клиента «сейчас».

Наша организация по разработке фактически столкнулась с некоторыми проблемами с этим несколько лет назад. Не все машины разработчика были синхронизированы с одним и тем же источником времени, как сервер, на котором находился SCM (и, возможно, не были синхронизированы с каким-либо источником времени, поэтому время машины разработчика могло дрейфовать). Машина разработчика может быть отключена через несколько месяцев. Я не помню всех проблем, но похоже, что процесс сборки пытался изменить все файлы с определенного времени (последняя сборка). Со времени последней сборки могли быть проверены файлы, время изменения которых (с клиента) происходило ДО последней сборки.

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

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

Answer 3

Вы можете взглянуть на унисон .Он основан на файлах, но вы можете найти некоторые идеи интересными.