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

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

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

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

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

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

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

Джонни: "У меня есть эта карточка".
Davey - "У меня есть куча карточек. Дайте мне эту карточку".
Джонни - "Вот твоя карта. Дай мне кучу карточек".
Дейви - "Вот твоя группа карт".
....
Оба - "Мы закончили"

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

Легко реализовать
Единственное свойство, используемое для синхронизации.

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

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

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

Не нужно сохранять временную метку одноранговой сети. 2 одноранговых узла могут запускать сеанс синхронизации и запускать синхронизацию на основе содержимого.
Хорошо определенная конечная точка для синхронизации - когда обе стороны имеют одинаковые наборы.
Разрешает одноранговую архитектуру, где любой одноранговый узел может выступать в роли клиента или сервера, обеспечивая возможность размещения HTTP-сервера.
Sync работает с содержимым наборов, а не с абстрактным временем концепции.
Поскольку синхронизация построена вокруг содержимого, синхронизация может быть использована для проверки содержимого, если это необходимо. Например. хэш файл SHA-1 может быть вычислен на контент и использоваться как uuid. Его можно сравнить с тем, что отправлено во время синхронизации.
Кроме того, хеши SHA-1 могут основываться на предыдущих хэшах, чтобы поддерживать согласованную историю содержимого.

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

Вы можете посмотреть unison. Он основан на файлах, но вы можете найти некоторые интересные идеи.