1. Sincronizzazione completa
Suggerirei sempre di sviluppare una sincronizzazione completa. Anche se hai una sincronizzazione parziale, non è sbagliato fare una sincronizzazione completa di tanto in tanto per assicurarti che tutto sia ancora in ordine.
Tieni presente che non puoi pianificare una sincronizzazione completa, ma tenerla manualmente attivabile da chiunque supporti l'applicazione.
2. Sincronizzazione basata su eventi - Prima interpretazione
Ero un po 'confuso riguardo alla tua spiegazione qui. Inizialmente, l'ho capito come un evento che è stato attivato da B , in modo da ottenere un aggiornamento immediato quando un determinato elemento è stato aggiornato in B.
Il vantaggio di farlo è un tempo di replica molto rapido, sei immediatamente consapevole di eventuali modifiche. Riduce anche le dimensioni del trasferimento dei dati.
Come svantaggio, i sistemi basati su eventi sono spesso più difficili da eseguire il debug.
Ti imbatti anche nel problema di cosa succede quando la connessione di rete tra A e B viene interrotta (o quando A è offline) ma B sta ancora elaborando gli aggiornamenti. L'unico modo per ovviare a questo problema è che B doveva avere una coda di messaggi in cui gli eventi persi venivano archiviati fino a quando non hai confermato di averli ricevuti, ma suppongo che tu non abbia alcun controllo sullo sviluppo di B.
Ecco perché vuoi avere una sincronizzazione completa una volta ogni tanto. Corregge tutti i problemi che possono essersi verificati in un punto o nell'altro.
Would a combination of event based sync and full sync (less frequent) do the job?
Quindi, se questa interpretazione è corretta; allora sei corretto sul fatto che una sincronizzazione parziale basata sugli eventi sarebbe meglio con una sincronizzazione completa poco frequente per risolvere problemi inevitabili che potrebbero verificarsi una volta ogni tanto.
2. Sincronizzazione basata su eventi - Seconda interpretazione
Ma in una rilettura, è iniziato ad apparire come se B non fosse coinvolto negli eventi. Stai pianificando di eseguire diverse operazioni di sincronizzazione e vuoi concatenarle una dopo l'altra utilizzando gli eventi internamente nella tua applicazione.
Ci sono molti modi per ottenere un'orchestrazione delle operazioni di sincronizzazione. Sincrono, asincrono, programmato, innescato, pilotato da un evento, ...
Tuttavia, il focus della tua domanda sembra essere quello di massimizzare la correttezza dei dati mantenendo al minimo l'utilizzo della rete. Il modo in cui gestisci le cose internamente nella tua applicazione non ha alcuna influenza su questo (salvo eventuali errori nel tuo codice che sembrano nuovamente fuori portata per la domanda in questione).
C'è una terza opzione qui, ma richiederebbe che B implementasse anche questo.
3. Sincronizzazione differenziale .
La differenza chiave tra una sincronizzazione differenziale e una sincronizzazione completa è che una sincronizzazione differenziale ti fornisce solo gli elementi che sono stati aggiornati dall'ultima volta che hai sincronizzato .
Questo ti offre i vantaggi di una sincronizzazione completa (ad esempio quando controlli gli aggiornamenti), ma riduce l'utilizzo della rete rimuovendo gli articoli che non richiedono aggiornamenti (poiché non sono stati comunque modificati).
Le sincronizzazioni differenziali possono venire in molti gusti diversi:
- B potrebbe tracciare quando hai effettuato l'ultima sincronizzazione. Oppure A potrebbe essere necessario per passare un timestamp in modo che A possa scegliere di ripetere un'operazione di sincronizzazione precedente utilizzando un timestamp più vecchio o eseguire una sincronizzazione completa omettendo il timestamp. (Preferisco quest'ultima opzione).
- B potrebbe inviarti i completi dati degli articoli aggiornati, oppure potrebbe solo inviarti i campi aggiornati degli articoli degli aggiornamenti. Quest'ultimo è molto più efficiente in termini di utilizzo della rete, ma è notoriamente più complesso da implementare sia sul lato A che su quello B.
Questo è il principio su cui si basano gli strumenti di controllo delle versioni come Git o SVN. Riduce drasticamente l'utilizzo dei dati (poiché un aggiornamento di solito modifica solo una piccola parte dell'intero), ma richiede più logica di gestione dei dati rispetto a una sincronizzazione completa (che è un'operazione di sovrascrittura semplice).
Tuttavia, ciò richiede che B sviluppi la funzione di sincronizzazione differenziale. Non puoi farlo da solo (a meno che tu non sia già in grado di eseguire una query sui campi "ultimo aggiornamento").
Nota
Se gli elementi possono essere eliminati sul lato di B, una sincronizzazione differenziale può diventare un problema. Se l'elemento A non fa parte dei dati di sincronizzazione differenziale, ciò potrebbe significare o che A è stato rimosso, o semplicemente A non è stato ancora aggiornato.
Tuttavia, mi aspetto che molti sistemi implementino un'eliminazione software; che risolve il problema in quanto un soft delete è un aggiornamento dell'elemento.
Se B consente le eliminazioni difficili; quindi non puoi utilizzare una sincronizzazione differenziale (a meno che B non sia in grado di aggiornarti anche sulle eliminazioni).