Synchronizacja między dwoma systemami wykorzystującymi MongoDB jako dziennik zmian

Opracowujemy dwa powiązane systemy. Jeden z nich (A) zostanie zainstalowany na maszynach naszych klientów. Pozostałe (B) zostaną wykorzystane przez moją organizację.

Każdy system ma własną bazę danych (relacyjną), a ich schematy są różne. Jednak oba systemy muszą być zsynchronizowane. Ponadto niektóre zmiany B należy wyeksportować do wszystkich systemów klasy A, a inne tylko do określonego.

Niektórzy klienci nie mają połączenia z Internetem, dlatego w niektórych przypadkach synchronizacja musi odbywać się poprzez wymianę plików.

Planujemy więc rozwiązać ten problem w następujący sposób:

1. Każdy system utrzymuje dziennik zmian swojej bazy danych. Planujemy wdrożyć go w MongoDB.
2. Gdy system inicjuje proces synchronizacji, pobiera wszystkie wprowadzone zmiany z dziennika. Jeśli system to B, odzyskane zmiany zależą od miejsca docelowego. Następnie system serializuje je w formacie XML i na koniec wysyła je (za pomocą pliku lub sieci).
3. Gdy drugi punkt końcowy otrzymuje zestaw zmian, odserializuje je. Następnie system dokonuje pewnych przekształceń danych, które mogą być konieczne, i na koniec rejestruje zmiany. Na tym etapie, jeśli jest to konieczne, system musi rozwiązać konflikty, które mogą istnieć.
4. Na koniec system odbiorczy wysyła swoje zmiany (i inne produkty rozwiązywania konfliktów).

Czy to podejście jest wykonalne, skalowalne i eleganckie? Jakie zmiany lub uzupełnienia byś wprowadził?

Jeśli jeszcze tego nie zrobiłeś, możesz przeczytać ciekawe informacje na temat systemów sterowanych zdarzeniami, pozyskiwania zdarzeń i ostatecznej spójności. Opisany system ma wiele podobieństw z tymi wzorami, co jest dobrą rzeczą.

Twoje podejście brzmi dobrze, w szczególności:

• Zastosowanie uporządkowanego dziennika zmian oznacza, że ​​proces synchronizacji jest w stanie pobrać tylko zmiany dokonane od czasu ostatniej zmiany. Pozwoli to skrócić czas przetwarzania, co pomoże zwiększyć skalowalność i pozwoli zbudować synchronizację w czasie zbliżonym do rzeczywistego w przypadkach, gdy dostępna jest łączność internetowa.
• Klienci nieposiadający połączenia internetowego zmuszają Cię do myślenia o radzeniu sobie z opóźnioną i niesprawną synchronizacją, zamiast polegać na szybkiej synchronizacji i nieumyślnie skończyć z problemami skalowalności.

Nie wiedząc więcej o modelu domeny, domyślam się, że rozwiązywanie konfliktów jest częścią, która sprawi ci najwięcej problemów. Spędziłbym trochę czasu zastanawiając się, jak rozwiązać każdy rodzaj konfliktu. W szczególności:

• Czy niektóre konflikty wymagają rozwiązania przez użytkownika?
• Czy system klienta zawsze będzie właściwym miejscem do rozwiązywania konfliktów?
• Czy możliwe są konflikty w systemie B po kroku 4, gdy system klienta wysyła swoje zmiany?

Każdy system utrzymuje dziennik zmian swojej bazy danych. Planujemy wdrożyć go w MongoDB.

Możesz użyć sklepu z wydarzeniami . Tam jakakolwiek aktualizacja danych stworzy nowe wydarzenie w sklepie.

Gdy system inicjuje proces synchronizacji, pobiera wszystkie wprowadzone zmiany z dziennika. Jeśli system to B, odzyskane zmiany zależą od miejsca docelowego. Następnie system serializuje je w formacie XML i na koniec wysyła je (za pomocą pliku lub sieci).

Możesz użyć dowolnego mechanizmu do wysyłania zdarzeń, ale łatwiej byłoby użyć magistrali, jeśli to możliwe, gdzie nie musisz zajmować się plikami. Zazwyczaj mogą one być skonfigurowane do przechowywania wiadomości, dopóki nie będzie dostępna łączność, aby je wysłać.

Gdy drugi punkt końcowy otrzymuje zestaw zmian, odserializuje je. Następnie system dokonuje pewnych przekształceń danych, które mogą być konieczne, i na koniec rejestruje zmiany. Na tym etapie, jeśli jest to konieczne, system musi rozwiązać konflikty, które mogą istnieć.

Po prostu zastosuj zdarzenia do obiektów swojej domeny.

Na koniec system odbiorczy wysyła swoje zmiany (i inne produkty rozwiązywania konfliktów).

Zastosuj to samo podejście.