Стратегия автономной / онлайн синхронизации данных

Question

Мое требование: у меня есть серверное веб-приложение J2EE и клиентское веб-приложение J2EE. Иногда клиент может выйти в автономный режим. Когда клиент входит в сеть, он должен иметь возможность синхронизировать изменения туда и сюда. Также я должен быть в состоянии контролировать, какие строки / таблицы должны быть синхронизированы, основываясь на некоторых фильтрах / правилах. Существуют ли какие-либо Java-фреймворки для этого? Если мне нужно реализовать самостоятельно, какие стратегии вы можете предложить?

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

Answer 1

Существует несколько библиотек Java для синхронизации / репликации данных. Два, о которых я знаю, это нарцисс и SymmetricDS . В прошлой жизни я по глупости реализовал (на Java) свой собственный процесс репликации данных. Это похоже на то, что должно быть довольно просто, но если данные могут обновляться одновременно в нескольких местах, это адски сложно. Я настоятельно рекомендую вам использовать один из вышеупомянутых проектов, чтобы попытаться обойти эту сложность самостоятельно.

Answer 2

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

Метод обычно состоит в том, чтобы добавить поле «измененное» во все таблицы и сравнить измененное поле клиента для данной записи в данной строке с датой изменения сервера. Если они не совпадают, вы заменяете данные сервера.

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

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

Answer 3

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

Answer 4

Что лучше всего подходит в качестве хранилища данных на стороне клиента в вашем приложении? Вы можете выбрать из встроенной базы данных, такой как SQLite, очередь сообщений, хранилище объектов или (если ни один из них нельзя использовать, поскольку это веб-приложение), файлы / документы, сохраненные на клиенте с использованием веб-базы данных или IndexedDB через HTML 5 LocalStorage API.

Проверьте документ Золотая лихорадка: промежуточное ПО для мобильных транзакций с репликацией Java-объектов . Документация Microsoft по иногда подключенным системам описывает два подхода: сервис-ориентированный или ориентированный на сообщения и ориентированный на данные. Золотая лихорадка использует более ранний подход. В последнем подходе используется слияние-репликация базы данных.