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

Question

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

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

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

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

Answer 1

Простейший подход: при синхронизации, передаче всех записей where updated_at >= @last_sync_at. Вниз: этот подход не терпит перекоса часов очень хорошо.

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

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

Answer 2

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

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

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

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

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

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

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

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

https://softwareengineering.stackexchange.com/questions/94634/synchronization-web-service-methodologies-or-papers