Синхронизация между двумя системами с использованием MongoDB в качестве журнала изменений

Мы разрабатываем две взаимосвязанные системы. Один из них (A) будет установлен на машинах наших клиентов. Остальные (B) будут использоваться моей организацией.

Каждая система имеет свою собственную базу данных (реляционную), и их схемы различаются. Однако обе системы должны быть синхронизированы. Кроме того, некоторые изменения в B необходимо экспортировать во все системы класса A, а другие - только в конкретную.

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

Итак, мы планируем решить эту проблему следующим образом:

1. Каждая система ведет журнал изменений своей базы данных. Мы планируем реализовать это с MongoDB.
2. Когда система инициализирует процесс синхронизации, она извлекает все внесенные изменения из журнала. Если система B, полученные изменения зависят от пункта назначения. Затем система сериализует их в формате XML и, наконец, отправляет их (через файл или сеть).
3. Когда другая конечная точка получает набор изменений, она десериализует их. Затем система выполняет некоторые преобразования данных, которые могут быть необходимы, и, наконец, записывает изменения. На этом этапе, если это необходимо, система должна разрешить конфликты, которые могут существовать.
4. Наконец, система-получатель отправляет свои изменения (и другие продукты разрешения конфликтов).

Является ли этот подход осуществимым, масштабируемым и элегантным? Какие изменения или дополнения вы бы сделали?

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

Ваш подход звучит хорошо, в частности:

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

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

• Будут ли некоторые конфликты требовать разрешения пользователя?
• Система клиентов всегда будет правильным местом для разрешения конфликтов?
• Возможны ли конфликты в системе B после шага 4, когда система клиентов отправляет свои изменения?

Каждая система ведет журнал изменений своей базы данных. Мы планируем реализовать это с MongoDB.

Вы можете использовать хранилище событий . Там любое обновление данных создаст новое событие в магазине.

Когда система инициализирует процесс синхронизации, она извлекает все внесенные изменения из журнала. Если система B, полученные изменения зависят от пункта назначения. Затем система сериализует их в формате XML и, наконец, отправляет их (через файл или сеть).

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

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

Просто примените события к объектам вашего домена.

Наконец, система-получатель отправляет свои изменения (и другие продукты разрешения конфликтов).

Используйте тот же подход.