Синхронізація з офлайн-системою

Я розробляю систему, з якої буду синхронізувати бізнес-дані з мобільного пристрою (у якого є вбудована програма), яка генерує дані та відсилає їх назад на сервер. Кожен рядок, синхронізований, генерує певний журнал бізнесу в базі даних.

Якщо те, що я синхронізую, генерує дані з датою (у межах даних синхронізації), що поступається останній даті модифікації моїх бізнес-даних, я повинен проігнорувати їх та просто додати базу даних журналу. Після опрацювання завантажених даних дані витягуються з бази даних та завантажуються на пристрій.

Через це завантаження відразу після написання синхронізація повинна бути синхронною. Можливо, все ще є модель читача / письменника, якщо щось подібне варто досить замінити моє існуюче рішення. Важливіше - мати можливість завантажувати актуальні дані. Ці дані отримані в цілому, на даний момент різниці не реалізовано (вони можуть з’явитися пізніше, але це не буде проблемою).

У мене може працювати декілька синхронізацій на одному бізнес-об’єкті, це малоймовірно, але може статися, і я вважаю за краще працювати з ним. Очікується, що синхронізація триватиме кілька секунд, але не декілька хвилин, якщо не використовувати вбудований мобільний додаток без повторної синхронізації протягом декількох днів.

Очікується, що обсяг синхронізованих даних не буде великим, як і процес синхронізації.

Отже, я використовую взаємне виключення щодо свого методу синхронізації, точніше, я використовую Java, і я ставлю синхронізований на метод запису не весь процес синхронізації, щоб не блокувати синхронізацію лише для читання.

Я хотів би знати :

1. Якщо цей спосіб має сенс? Поки гучність і час процесу синхронізації залишаються прийнятними.
2. Загалом, на які поняття слід звернути увагу. Бонус: якщо в модулі Spring є реалізація цих концепцій.

Один із підходів, який я деякий час досліджував (з певним успіхом), щоб синхронізувати дані клієнта з даними сервера, не покладаючись на дати (які можуть бути ненадійними) або синхронні запити, - це комбінація патчів JSON (можливо, POJO s у вашому випадку) та пошук подій .

Основна ідея полягає в тому, що замість того, щоб зберігати поточний стан на клієнті та сервері, клієнт і сервер зберігають список змін та повідомляють один одного через події або запити виправлення.

Отже, замість того, щоб клієнт надсилав усі дані плюс дату на сервер, клієнт надсилає подію разом із номером ревізії, який відповідає останньому разу, коли клієнт думає, що дані оновились. Щось на зразок цього:

Server.send("MODIFY FOO", 3);

Як тільки сервер отримує цю подію (асинхронно), він узгоджує її з іншими подіями, які він, можливо, вже отримав. Наприклад, можливо, що інший клієнт, що працює з тими ж даними, можливо, вже змінив деякі речі, і тепер номер ревізії на сервері дорівнює 5. Таким чином, цю версію потрібно застосувати до того, як будуть застосовані останні 2, і всі клієнтам потрібно буде повідомити про цю зміну.

Після завершення роботи сервера він повідомляє всіх зацікавлених клієнтів про внесення змін та новий номер поточного перегляду. Потім клієнт застосовує ці зміни та оновлює свій внутрішній номер перегляду.

Ваш пробіг може відрізнятися, але я сподіваюся, що це допоможе.

Редагувати: інша назва цього підходу або його варіанту називається чергою повідомлень , як згадується в цьому пов'язаному питанні .

Перша проблема - використання дат як спосіб синхронізації даних. Я справді впевнений, що я не отримав усіх деталей вашого рішення, але я сказав би це:

1. Чи створюються дати на мобільних телефонах? У цьому випадку ви впевнені, що додаток, що працює на мобільних телефонах, завжди використовуватиме правильні дати? Що з шкідливим користувачем, який дещо може змінити системну дату на своєму мобільному пристрої? Що щодо користувачів у різних часових поясах? Як вам сказав @jeffrey, можливо, це не найкращий підхід покладатися на дати, створені на пристроях.

2. Якщо я правильно зрозумів, ви використовуєте оптимістичний контроль за сумісністю . Я не бачу нічого, що є інтрисично неправильним у вашому підході.

3. Це питання стосується впровадження оптимістичного блокування навесні . Можливо, ви можете знайти в цьому трохи натхнення.