Синхронізація між двома системами, що використовують MongoDB як журнал змін

Ми розробляємо дві суміжні системи. Один з них (A) буде встановлений на машинах наших клієнтів. Решта (B) буде використана моєю організацією.

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

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

Отже, ми плануємо вирішити цю проблему наступним чином:

1. Кожна система підтримує журнал змін своєї бази даних. Ми плануємо реалізувати це разом з MongoDB.
2. Коли система ініціалізує процес синхронізації, вона отримує всі внесені зміни з журналу. Якщо система B, отримані зміни залежать від місця призначення. Потім система їх серіалізує у форматі XML і, нарешті, надсилає їх (через файл або мережу).
3. Коли інша кінцева точка отримує набір змін, вона їх несеріалізує. Потім система здійснює певні перетворення над даними, які можуть бути необхідними, і, нарешті, записує зміни. На цьому кроці, якщо це необхідно, система повинна вирішити конфлікти, які можуть існувати.
4. Нарешті, приймальна система надсилає свої зміни (та інші продукти вирішення конфлікту).

Чи підхід такий, здійсненний, масштабований та елегантний? Які зміни чи доповнення ви б внесли?

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

Ваш підхід звучить добре, зокрема:

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

Не знаючи більше про доменну модель, я здогадуюсь, що вирішення конфліктів - це та частина, яка доставить вам найбільше проблем. Я б провів деякий час, роздумуючи над тим, як вирішувати кожен вид конфлікту. Зокрема:

• Чи потребуватимуть вирішення конфлікту деякі користувачі?
• Чи завжди система клієнтів буде правильним місцем для вирішення конфліктів?
• Чи можливі конфлікти в системі B після кроку 4, коли система клієнтів надсилає свої зміни?

Кожна система підтримує журнал змін своєї бази даних. Ми плануємо реалізувати це разом з MongoDB.

Ви можете використовувати магазин подій . Там будь-яке оновлення даних створить нову подію в магазині.

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

Ви можете використовувати будь-який механізм для надсилання подій, але було б простіше використовувати шину, якщо можливо, там, де вам не доведеться мати справу з файлами. Як правило, вони можуть налаштовуватись на утримання повідомлень до тих пір, поки доступне з'єднання для надсилання.

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

Просто застосуйте події до об’єктів вашого домену.

Нарешті, приймальна система надсилає свої зміни (та інші продукти вирішення конфлікту).

Використовуйте той же підхід.