Sincronizzazione tra due sistemi che utilizzano MongoDB come log delle modifiche

Stiamo sviluppando due sistemi correlati. Uno di questi (A) verrà installato sulle macchine dei nostri clienti. Il restante (B) verrà utilizzato dalla mia organizzazione.

Ogni sistema ha il suo database (relazionale) e i loro schemi differiscono. Tuttavia, entrambi i sistemi devono essere sincronizzati. Inoltre, alcune modifiche in B devono essere esportate in tutti i sistemi di classe A e altre solo in uno specifico.

Alcuni clienti non dispongono di una connessione Internet, pertanto la sincronizzazione, in alcuni casi, deve essere effettuata tramite lo scambio di file.

Quindi, stiamo programmando di risolvere questo problema come segue:

1. Ogni sistema mantiene un log delle modifiche del proprio database. Stiamo programmando di implementarlo con MongoDB.
2. Quando un sistema inizializza un processo di sincronizzazione, recupera tutte le modifiche apportate da un registro. Se il sistema è B, le modifiche recuperate dipendono dalla destinazione. Quindi, il sistema li serializza in formato XML e, infine, li invia (tramite un file o una rete).
3. Quando l'altro endpoint riceve il changeset, li serializza. Quindi, il sistema esegue alcune trasformazioni sui dati, che possono essere necessarie e, infine, registra le modifiche. In questo passaggio, se necessario, il sistema deve risolvere i conflitti che potrebbero esistere.
4. Infine, il sistema ricevente invia le sue modifiche (e altri prodotti di risoluzione dei conflitti).

Questo approccio è fattibile, scalabile ed elegante? Quali modifiche o aggiunte faresti?

Se non lo hai già fatto, potresti trovare interessante leggere i sistemi basati sugli eventi, l'approvvigionamento degli eventi e l'eventuale coerenza. Il sistema che stai descrivendo ha molti parallelismi con questi schemi, il che è positivo.

Il tuo approccio suona bene, in particolare:

• L'uso di un log delle modifiche ordinato significa che il processo di sincronizzazione è in grado di recuperare solo le modifiche apportate dall'ultima modifica visualizzata. Ciò consentirà di ridurre i tempi di elaborazione, favorendo la scalabilità e consentendoti di creare una sincronizzazione quasi in tempo reale nei casi in cui è disponibile la connessione a Internet.
• I clienti senza connessione a Internet ti costringono a pensare a gestire subito la sincronizzazione ritardata e fuori servizio, piuttosto che affidarti a una sincronizzazione rapida e finire inavvertitamente con problemi di scalabilità.

Senza sapere di più sul modello di dominio, la mia ipotesi è che la risoluzione dei conflitti sia la parte che ti causerà più problemi. Passerei un po 'di tempo a pensare a come risolvere ogni tipo di conflitto. In particolare:

• Alcuni conflitti richiedono la risoluzione dell'utente?
• Il sistema dei clienti sarà sempre il posto giusto per risolvere i conflitti?
• È possibile che si verifichino conflitti nel sistema B dopo il passaggio 4 quando il sistema dei clienti invia le sue modifiche?

Ogni sistema mantiene un log delle modifiche del proprio database. Stiamo programmando di implementarlo con MongoDB.

È possibile utilizzare un negozio di eventi . Lì qualsiasi aggiornamento ai dati creerà un nuovo evento nel negozio.

Quando un sistema inizializza un processo di sincronizzazione, recupera tutte le modifiche apportate dal registro. Se il sistema è B, le modifiche recuperate dipendono dalla destinazione. Quindi, il sistema li serializza in formato XML e, infine, li invia (tramite un file o una rete).

È possibile utilizzare qualsiasi meccanismo per inviare eventi, ma sarebbe più semplice utilizzare un bus se possibile dove non è necessario gestire i file. In genere questi possono essere configurati per contenere i messaggi fino a quando non è disponibile la connettività per inviarli.

Quando l'altro endpoint riceve il changeset, li serializza. Quindi, il sistema esegue alcune trasformazioni sui dati, che possono essere necessarie e, infine, registra le modifiche. In questo passaggio, se necessario, il sistema deve risolvere i conflitti che potrebbero esistere.

Basta applicare gli eventi ai tuoi oggetti di dominio.

Infine, il sistema ricevente invia le sue modifiche (e altri prodotti per la risoluzione dei conflitti).

Usa lo stesso approccio.