Синхронизация объектов между двумя разнородными системами, лучший подход? - PullRequest
6 голосов
/ 12 марта 2009

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

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

Бизнес-объекты можно редактировать, удалять и обновлять с обеих сторон. Обе стороны могут хранить объект локально, но синхронизация инициируется только на стороне iPhone для автономного просмотра. Все объекты имеют метку времени updated_at и made_at и поддерживаются СУБД с обеих сторон (SQLite на стороне iPhone и MySQL в Интернете ... опять же, я не думаю, что это имеет большое значение), и телефон действительно записывает последний раз, когда попытка синхронизации была предпринята. В противном случае никакие другие данные не сохраняются (на данный момент).

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

Ответы [ 2 ]

11 голосов
/ 12 марта 2009

Самый простой подход: при синхронизации переносить все записи where updated_at >= @last_sync_at. Обратная сторона: этот подход не очень хорошо переносит перекос часов.

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

Для поддержки синхронизации удалений требуется некоторая форма софт-удалений, однако это может быть в форме «надгробной записи», которая содержит только ключ удаленной строки. Надгробия могут быть безопасно удалены только после того, как вы убедитесь, что все реплики обработали их, в противном случае распадающаяся реплика может воскресить запись, которую вы считали удаленной.

0 голосов
/ 31 марта 2012

Итак, я думаю, что в целом ваши вопросы относятся к отключенной синхронизации.

Итак, вот что, я думаю, должно произойти:

Начальная синхронизация Вы извлекаете данные и любую связанную с ними информацию (версии строк, контрольные суммы файлов и т. Д.). важно, чтобы вы хранили эту информацию и оставляли ее нетронутой до следующей успешной синхронизации. Необходимо внести изменения в КОПИЮ этих данных.

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

Проверка на конфликты Опять же, если вы имеете дело только со строками базы данных, конфликты легко обнаружить. У вас может быть другой столбец, который увеличивается при каждом обновлении строки (я думаю, что в mssql есть эта встроенная функция, не уверенная в mysql). Так что, если у вашей копии есть номер, отличный от того, что находится на сервере, то у вас конфликт. Для файлов или строк, контрольная сумма сделает работу. Я полагаю, вы также можете использовать модифицированную дату, но убедитесь, что у вас есть очень точное и точное измерение, чтобы избежать промахов. например: скажем, я получаю файл, а вы сохраняете его, как только я его получаю. Допустим, разница во времени составляет 1 миллисекунду. Затем я делаю изменения в файле, а затем пытаюсь сохранить его. Если записанное время последнего изменения имеет точность только до 10 миллисекунд, есть большая вероятность того, что в найденном мной файле будет та же дата изменения, что и в сохраненной вами, поэтому программа считает, что в ней нет конфликта, и перезаписывает ваши изменения. Поэтому я обычно не использую этот метод просто для того, чтобы быть в безопасности. С другой стороны, вероятность столкновения контрольной суммы / хеша после незначительной модификации близка к нулю.

Разрешение конфликтов Теперь это сложная часть. Если это автоматизированный процесс, вам придется оценить ситуацию и решить, хотите ли вы перезаписать изменения, потерять свои изменения или снова получить данные с сервера и попытаться повторить изменения. К счастью для вас, кажется, что будет человеческое взаимодействие. Но это все еще большая боль в коде. Если вы имеете дело со строками базы данных, вы можете проверить каждый отдельный столбец, сравнить его с данными на сервере и представить его пользователю. Идея состоит в том, чтобы представить конфликты пользователю очень детально, чтобы не перегружать их. Большинство конфликтов имеют очень небольшие различия во многих разных местах, поэтому представьте их пользователю по одной небольшой разнице за раз. Так что для текстовых файлов это почти то же самое, но более чем в сто раз сложнее. Таким образом, в основном вы должны будете создать или использовать инструмент сравнения (сравнение текста - это совершенно другая тема, и он слишком широк, чтобы упоминать здесь), который позволяет вам узнать о небольших изменениях в файле и о том, где они находятся аналогично база данных: где текст был вставлен, удален или отредактирован. Затем представьте это пользователю таким же образом. поэтому в основном для каждого небольшого конфликта пользователь должен будет выбрать, следует ли отменить свои изменения, перезаписать изменения на сервере или выполнить ручное редактирование перед отправкой на сервер.

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

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

Источник: https://softwareengineering.stackexchange.com/questions/94634/synchronization-web-service-methodologies-or-papers

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...