Я разрабатываю систему, из которой я буду синхронизировать бизнес-данные с мобильного устройства (у которого есть встроенное приложение), которое генерирует данные и отправляет их обратно на сервер. Каждая синхронизированная строка генерирует определенный бизнес-журнал в базе данных.
Если то, что я синхронизирую, генерирует данные с датой (в пределах данных синхронизации) ниже даты последнего изменения моих бизнес-данных, я должен проигнорировать это и просто добавить базу данных для входа. Как только загруженные данные обработаны, данные извлекаются из базы данных и загружаются на устройство.
Из-за этой загрузки сразу после записи синхронизация должна быть синхронной. Можно по-прежнему иметь шаблон чтения / записи, если что-то подобное стоит того, чтобы заменить мое существующее решение. Более важно иметь возможность загружать новейшие данные. Эти данные извлекаются как единое целое, в настоящий момент не реализовано diff (оно может появиться позже, но это не будет проблемой).
У меня может быть несколько синхронизаций на одном и том же бизнес-объекте, это маловероятно, но может случиться, и я предпочитаю иметь возможность справиться с этим. Ожидается, что синхронизация продлится несколько секунд, но не несколько минут, если только в течение нескольких дней не используется встроенное мобильное приложение без повторной синхронизации.
Объем синхронизированных данных не ожидается большим, как и процесс синхронизации.
Поэтому я использую взаимное исключение в моем методе синхронизации, точнее говоря, я использую Java, и я включил синхронизированный метод записи, а не весь процесс синхронизации, чтобы не блокировать синхронизацию только для чтения.
Я бы хотел знать :
- Если этот способ имеет смысл? Пока объем и время процесса синхронизации все еще приемлемы.
- В общем, какие концепции я должен смотреть. Бонус: если есть какая-либо реализация этих концепций в модуле Spring.
источник
Ответы:
Одним из подходов, который я уже некоторое время исследую (с некоторым успехом), чтобы синхронизировать данные клиента с данными сервера, не полагаясь на даты (которые могут быть ненадежными) или синхронные запросы, является комбинация JSON Patches (возможно, POJO s). в вашем случае) и событие сорсинга .
Основная идея состоит в том, что вместо сохранения текущего состояния на клиенте и сервере клиент и сервер сохраняют список изменений и сообщают друг другу либо через события, либо запросы на исправление.
Таким образом, вместо того, чтобы клиент отправлял все данные плюс дату на сервер, клиент отправляет событие вместе с номером редакции, который соответствует времени, когда клиент думал, что данные обновлены. Что-то вроде этого:
Как только сервер получает это событие (асинхронно), он согласовывает его с другими событиями, которые он, возможно, уже получил. Например, возможно, что другой клиент, работающий с теми же данными, уже изменил некоторые вещи, и теперь номер редакции на сервере равен 5. Таким образом, эту редакцию нужно будет применить до того, как будут применены последние 2, и все клиенты должны быть уведомлены об этом изменении.
После завершения работы сервера он уведомляет всех заинтересованных клиентов об изменениях и новом текущем номере редакции. Затем клиент применяет эти изменения и обновляет свой внутренний номер редакции.
Ваш пробег может отличаться, но я надеюсь, что это поможет.
Изменить. Другое название этого подхода или его разновидности называется очередью сообщений , как упоминалось в этом связанном вопросе .
источник
Первая проблема - использование дат как способа синхронизации данных. Я действительно уверен, что не получил все детали вашего решения, но я бы сказал, что:
Даты генерируются на мобильных телефонах? В этом случае вы уверены, что приложение, работающее на мобильных устройствах, всегда будет использовать правильные даты? Как насчет злоумышленника, который может изменить системную дату на своем мобильном устройстве? А как насчет пользователей в разных часовых поясах? Как сказал @jeffrey, возможно, это не лучший способ полагаться на даты, сгенерированные на устройствах.
Если я правильно понял, вы используете Optimistic Concurrency Control . Я не вижу ничего, что было бы по сути неправильно в вашем подходе.
Этот вопрос касается реализации Оптимистической блокировки весной . Может быть, вы можете найти вдохновение в этом.
источник