Risoluzione dei conflitti per sincronizzazione bidirezionale

La solita soluzione per sapere "quale modifica è corretta" è un orologio vettoriale . In pratica, tieni traccia dei contatori per ogni repository che contiene i dati e rifiuta le modifiche se la vista di un particolare cliente dello stato di tutti gli altri è diversa da quella del peer a cui si connette.

La grande domanda a cui devi rispondere è come risolverete i salvataggi respinti. Questo generalmente significa una sorta di operazione di unione.

Si noti che gli orologi vettoriali non usano timestamp in tempo reale. I problemi legati alla sincronizzazione degli orologi in tempo reale sono almeno altrettanto difficili della sincronizzazione dei dati.

Questo è il problema Generici bizantini , che è irrisolvibile. Non puoi mai garantire sincronizzare i due server se non puoi garantire in futuro , avrai sufficiente larghezza di banda affidabile per eseguire la sincronizzazione tutto in una volta.

Suppongo che non ci sia un modo standard per farlo, ogni sistema usa le proprie politiche per la risoluzione dei conflitti.

Ho realizzato alcune simulazioni utilizzando due dispositivi, computer e telefono e Google Spreadsheet per verificare in che modo Google Documenti gestisce i conflitti automaticamente. Ecco alcuni casi:

Caso 1

1. Computer e telefono non sono in linea
2. Computer modifica cella con valore 'computer' e dopo telefono modifica cella con valore 'telefono'
3. Il computer diventa online
4. Il telefono diventa online e sia il computer che il telefono visualizzano il "telefono".

Caso 2

1. Computer e telefono non sono in linea
2. Computer modifica cella con valore 'computer' e dopo telefono modifica cella con valore 'telefono'
3. Il telefono diventa online
4. I computer diventano online e sia il computer che il telefono visualizzano il 'computer'.

Quindi almeno il server di Google Documenti utilizza gli ultimi dati ricevuti come priorità più elevata indipendentemente da quando è stato creato (data / ora del client). Ho anche testato se eseguivano la sincronizzazione in background e apparentemente no, quindi il risultato della risoluzione del conflitto è trasparente per l'utente.

GIT in altra mano, non gestisce i conflitti automaticamente, ma invece delega all'ultimo utente che stava cercando di modificare il repository come dovrebbe essere fatto l'unione.

Io opterei per l'approccio di Google Docs se va bene solo la sincronizzazione in primo piano, con l'utente che visualizza i dati. In caso contrario, un utente potrebbe rimanere sorpreso dal fatto che, mentre il suo telefono si collegava automaticamente a una rete WiFi, una modifica non sincronizzata a una riunione che lui, dopo essere stata rimodificata sul suo PC, è stata attivata.

Vado per l'approccio timestamp del client, sovrascrivendo i conflitti con l'ultima modifica, se hai bisogno di una sincronizzazione in background, possiamo fidarci del timestamp del client e il costo di un'indesiderata unione è minore del costo di richiedere all'utente di scegliere quale versione che vuole mantenere.

Preferirei l'approccio GIT altrimenti, mostrando un popup nel prossimo client in foreground chiedendo all'utente di scegliere quale versione conservare o dare la possibilità di annullare l'unione.