Risoluzione dei conflitti per la sincronizzazione bidirezionale

Come gestite la sincronizzazione bidirezionale tra un server di database "principale" e molti server "secondari", in particolare la risoluzione dei conflitti, supponendo che una connessione non sia sempre disponibile?

Ad esempio, ho un'app mobile che utilizza CoreData come "database" su iOS e vorrei consentire agli utenti di modificare i contenuti senza connessione a Internet. Allo stesso tempo, queste informazioni sono disponibili su un sito Web a cui si collegheranno i dispositivi. Cosa devo fare se / quando i dati sui due server DB sono in conflitto?
(Mi riferisco a CoreData come un server DB, anche se sono consapevole che è qualcosa di leggermente diverso.)

Esistono strategie generali per affrontare questo tipo di problema? Queste sono le opzioni che mi vengono in mente:
1. Usa sempre i dati sul lato client come priorità più alta
2. Lo stesso per il lato server
3. Prova a risolvere i conflitti contrassegnando il timestamp di modifica di ciascun campo e prendendo l'ultima modifica

Anche se sono sicuro che la terza opzione aprirà spazio per un danneggiamento devastante dei dati.

Sono consapevole che il teorema della PAC riguarda questo, ma voglio solo un'eventuale coerenza, quindi non lo esclude completamente, giusto?

Domanda correlata: modelli di best practice per la sincronizzazione dei dati bidirezionale . La seconda risposta a questa domanda dice che probabilmente non può essere fatto.

La solita soluzione per sapere "quale modifica è corretta" è un orologio vettoriale . In sostanza, si tiene traccia dei contatori per ciascun repository che contiene i dati e si rifiutano le modifiche se la visione di un particolare cliente dello stato di tutti gli altri differisce da quella del peer a cui si sta connettendo.

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

Si noti che gli orologi vettoriali non utilizzano timestamp in tempo reale. I problemi legati alla sincronizzazione degli orologi in tempo reale sono difficili almeno quanto la sincronizzazione dei dati.

Questo è il problema dei generali bizantini , che è irrisolvibile. Non è mai possibile garantire la sincronizzazione dei due server se non è possibile garantire che in un determinato momento in futuro si disponga di una larghezza di banda sufficiente e affidabile per eseguire la sincronizzazione tutto in una volta.

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

Ho fatto alcune simulazioni utilizzando due dispositivi, computer e telefono e foglio di calcolo di Google per verificare come Google Docs gestisce automaticamente i conflitti. Ecco alcuni casi:

Caso 1

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

Caso 2

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

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

GIT, d'altra parte, non gestisce automaticamente i conflitti, ma invece delega all'ultimo utente che stava cercando di modificare il repository su come eseguire l'unione.

Preferirei l'approccio di Google Documenti se va bene solo la sincronizzazione in primo piano, con l'utente che visualizza i dati. Altrimenti, un utente potrebbe essere sorpreso dal fatto che mentre il suo telefono si connetteva automaticamente a un WiFi, una modifica non sincronizzata a una riunione che dopo aver modificato nuovamente sul suo PC fosse attiva.

Preferirei l'approccio data / ora del client, ignorando i conflitti con l'ultima modifica, se hai bisogno di una sincronizzazione in background, posso fidarmi della data / ora del client e il costo di una fusione indesiderata è inferiore al costo di richiedere all'utente di scegliere quale versione desidera tenere.

Vorrei scegliere l'approccio GIT in caso contrario, mostrando un popup nel primo client in primo piano chiedendo all'utente di scegliere quale versione conservare o dando la possibilità di ripristinare l'unione.