변경 로그로 MongoDB를 사용하는 두 시스템 간의 동기화

우리는 두 가지 관련 시스템을 개발하고 있습니다. 그 중 하나 (A)가 고객의 컴퓨터에 설치됩니다. 나머지 (B)는 내 조직에서 사용됩니다.

각 시스템에는 자체 데이터베이스 (관계형)가 있으며 스키마가 다릅니다. 그러나 두 시스템 모두 동기화되어야합니다. 또한 B의 일부 변경 사항은 모든 클래스 A 시스템으로 내보내고 다른 시스템은 특정 시스템으로 만 내 보내야합니다.

일부 고객은 인터넷에 연결되어 있지 않으므로 일부 경우 파일 교환을 통해 동기화를 수행해야합니다.

따라서이 문제를 다음과 같이 해결할 계획입니다.

1. 각 시스템은 데이터베이스의 변경 로그를 유지 관리합니다. 우리는 그것을 MongoDB로 구현할 계획입니다.
2. 시스템이 동기화 프로세스를 초기화하면 로그에서 모든 변경 사항을 검색합니다. 시스템이 B 인 경우 검색된 변경 사항은 대상에 따라 다릅니다. 그런 다음 시스템은이를 XML 형식으로 직렬화하고 마지막으로 파일 또는 네트워크를 통해 전송합니다.
3. 다른 엔드 포인트가 변경 세트를 수신하면 직렬화 해제됩니다. 그런 다음 시스템은 데이터에 대해 일부 변환을 수행하여 필요할 수 있으며 마지막으로 변경 사항을 기록합니다. 이 단계에서 필요한 경우 시스템은 존재할 수있는 충돌을 해결해야합니다.
4. 마지막으로, 리시버 시스템은 변경 사항 및 기타 충돌 해결 제품을 보냅니다.

이 접근법은 실현 가능하고 확장 가능하며 우아합니까? 어떤 변경이나 추가를 원하십니까?

아직 수행하지 않은 경우 이벤트 중심 시스템, 이벤트 소싱 및 최종 일관성을 읽는 것이 흥미로울 수 있습니다. 설명하는 시스템에는 이러한 패턴과 많은 유사점이 있습니다.

다음과 같은 접근 방식이 좋습니다.

• 정렬 된 변경 로그를 사용한다는 것은 동기화 프로세스가 마지막으로 본 변경 이후의 변경 사항 만 검색 할 수 있음을 의미합니다. 이렇게하면 처리 시간이 단축되어 확장 성이 향상되며 인터넷 연결이 가능한 경우 거의 실시간 동기화를 구축 할 수 있습니다.
• 인터넷에 연결되어 있지 않은 고객은 빠른 동기화에 의존하고 부주의하게 확장 성 문제를 끝내기보다는 지연되고 비 순차적 동기화를 처리해야합니다.

도메인 모델에 대해 더 많이 알지 못하면 충돌을 해결하는 것이 가장 문제가되는 부분이라고 생각합니다. 나는 각 종류의 갈등이 어떻게 해결 될지 생각하면서 시간을 보냈다. 특히:

• 일부 충돌에는 사용자 확인이 필요합니까?
• 고객 시스템은 항상 갈등을 해결하기위한 올바른 장소입니까?
• 고객 시스템이 변경 사항을 전송할 때 4 단계 후에 시스템 B에 충돌이있을 수 있습니까?

각 시스템은 데이터베이스의 변경 로그를 유지 관리합니다. 우리는 그것을 MongoDB로 구현할 계획입니다.

이벤트 저장소 를 사용할 수 있습니다 . 데이터가 업데이트되면 상점에 새로운 이벤트가 생성됩니다.

시스템이 동기화 프로세스를 초기화하면 로그에서 작성된 모든 변경 사항을 검색합니다. 시스템이 B 인 경우 검색된 변경 사항은 대상에 따라 다릅니다. 그런 다음 시스템은이를 XML 형식으로 직렬화하고 마지막으로 파일 또는 네트워크를 통해 전송합니다.

모든 메커니즘을 사용하여 이벤트를 보낼 수 있지만 가능한 경우 파일을 처리 할 필요가없는 경우 버스를 사용하는 것이 더 쉽습니다. 일반적으로 연결을 사용할 수있을 때까지 메시지를 보관하도록 구성 할 수 있습니다.

다른 엔드 포인트가 변경 세트를 수신하면 직렬화 해제됩니다. 그런 다음 시스템은 데이터에 대해 일부 변환을 수행하여 필요할 수 있으며 마지막으로 변경 사항을 기록합니다. 이 단계에서 필요한 경우 시스템은 존재할 수있는 충돌을 해결해야합니다.

이벤트를 도메인 개체에 적용하기 만하면됩니다.

마지막으로, 리시버 시스템은 변경 사항 (및 기타 충돌 해결 제품)을 보냅니다.

같은 접근법을 사용하십시오.