Quali sono le insidie ​​più comuni della sincronizzazione basata sul timestamp?

Question

Sto implementando il mio primo codice di sincronizzazione. Nel mio caso avrò 2 tipi di client iOS per utente che sincronizzeranno i record su un server usando un lastSyncTimestamp, un numero intero a 64 bit che rappresenta l'epoca Unix in millisecondi dell'ultima sincronizzazione. I record possono essere creati sul server o sui client in qualsiasi momento e i record vengono scambiati come JSON su HTTP.

Non sono preoccupato per i conflitti poiché ci sono pochi aggiornamenti e sempre dallo stesso utente. Tuttavia, mi chiedo se ci siano cose comuni di cui ho bisogno di essere consapevole che possono andare storto con un approccio basato sul timestamp come la sincronizzazione durante l'ora legale, la sincronizzazione con altri o con altri trucchi.

So che git e qualche altro sistema di controllo della versione evitano la sincronizzazione con i timestamp per un approccio di sincronizzazione della negoziazione basato sul contenuto. Potrei immaginare un approccio simile anche per le mie app, dove usando lo uuid o lo hash degli oggetti, entrambi i peer annunciano quali oggetti possiedono e quindi li scambiano fino a quando entrambi i peer hanno gli stessi set.

Se qualcuno conosce vantaggi o svantaggi della sincronizzazione basata sul contenuto rispetto alla sincronizzazione basata sul timestamp in generale, sarebbe altrettanto utile.

Modifica - Ecco alcuni dei vantaggi/svantaggi che ho trovato per il timestamp e la sincronizzazione basata sul contenuto. Si prega di contestare/correggere.

Nota - Io sono la definizione dei contenuti a base di sincronizzazione semplice negoziazione di 2 set di oggetti come ad esempio la 2 bambini si scambiavano le carte, se ha dato loro ogni parti di un mucchio jumbled da 2 serie identiche di carte di baseball e ha detto loro che mentre li guardano per annunciare e consegnare qualsiasi duplicato trovato all'altro finché non hanno entrambi set identici.

• Johnny - "Ho preso questa carta".
• Davey - "Ho preso questo mazzo di carte, dammi quella carta".
• Johnny - "Ecco la tua carta, dammi quel mazzo di carte."
• Davey - "Ecco il tuo mazzo di carte."
• ....
• Entrambi - "abbiamo finito"

Vantaggi di timestamp a base di sincronizzazione

• Facile da implementare
• immobili singolo utilizzato per la sincronizzazione.

Svantaggi di timestamp a base di sincronizzazione

• Il tempo è un concetto relativo all'osservatore e gli orologi della macchina differente può essere fuori sincrono. Ci sono un paio di modi per risolvere questo. Genera timestamp su una singola macchina, che non scala bene e rappresenta un singolo punto di errore. O usare orologi logici come orologi vettoriali. Per lo sviluppatore medio che costruisce il proprio sistema, gli orologi vettoriali potrebbero essere troppo complessi da implementare.
• La sincronizzazione basata sul timestamp funziona per sincronizzare il client ma non funziona anche per la sincronizzazione peer-to-peer o laddove la sincronizzazione può avvenire con 2 master.
• Singolo punto di errore, qualsiasi cosa generi il timestamp.
• Il tempo non è realmente correlato al contenuto di ciò che viene sincronizzato.

Vantaggi di contenuti basati su sincronizzazione

• No al pari timestamp deve essere mantenuto. 2 peer possono avviare una sessione di sincronizzazione e avviare la sincronizzazione in base al contenuto.
• Endpoint ben definito da sincronizzare - quando entrambe le parti hanno set identici.
• Consente un'architettura peer-to-peer, in cui qualsiasi peer può agire come client o server, a condizione che possano ospitare un server HTTP.
• La sincronizzazione funziona con il contenuto degli insiemi, non con un tempo di concetto astratto.
• Poiché la sincronizzazione è basata sul contenuto, è possibile utilizzare la sincronizzazione per eseguire la verifica del contenuto, se lo si desidera. Per esempio. un hash SHA-1 può essere calcolato sul contenuto e utilizzato come uuid. Può essere paragonato a ciò che viene inviato durante la sincronizzazione.
• Inoltre, gli hash SHA-1 possono essere basati su hash precedenti per mantenere una cronologia coerente del contenuto.

Svantaggi di contenuti basati su sincronizzazione

• proprietà extra sul tuo oggetti possono essere necessarie da implementare.
• Più logica su entrambi i lati rispetto alla sincronizzazione basata sul timestamp.
• Un protocollo leggermente più chatty (questo potrebbe essere ottimizzato sincronizzando il contenuto nei cluster).

Answer 1

Non so se si applica nel proprio ambiente, ma si potrebbe considerare il cui tempo è "giusto", il client o il server (o se è importante)? Se tutti i client e tutti i server non sono sincronizzati alla stessa origine temporale, potrebbe esserci la possibilità, per quanto minima, di ottenere un risultato imprevisto da un client durante la sincronizzazione (o dal) del server utilizzando l'ora "ora" del client.

La nostra organizzazione di sviluppo si è imbattuta in alcuni problemi con questo diversi anni fa. Le macchine per gli sviluppatori non erano tutte sincronizzate con la stessa sorgente del server su cui risiedeva SCM (e potrebbero non essere state sincronizzate con qualsiasi sorgente del tempo, quindi il tempo della sviluppatrice potrebbe andare alla deriva). Una macchina per sviluppatori potrebbe essere in diversi minuti dopo alcuni mesi. Non ricordo tutti i problemi, ma sembra che il processo di compilazione abbia cercato di ottenere tutti i file modificati da una certa ora (l'ultima build). I file potevano essere archiviati, dall'ultima build, che aveva tempi di modifica (dal client) che si erano verificati PRIMA dell'ultima build.

Potrebbe essere che le nostre procedure SCM non erano proprio ottime, o che il nostro sistema SCM o il processo di costruzione erano indebitamente suscettibili a questo problema. Anche oggi, tutte le nostre macchine di sviluppo dovrebbero sincronizzare il tempo con il server su cui è installato il nostro sistema SCM.

Ancora una volta, questo è stato diversi anni fa e non riesco a ricordare i dettagli, ma volevo menzionarlo sulla possibilità che sia significativo nel tuo caso.

Answer 2

Parte del problema è che il tempo non è un concetto assoluto. Se qualcosa accade prima o dopo qualcos'altro è una questione di prospettiva, non di conformità con un orologio da parete.

documentarsi un po 'sul relativity of simultaneity per capire il motivo per cui le persone hanno smesso di cercare di usare il tempo a muro per capire queste cose e si sono spostati in costrutti che rappresentano la causalità reale utilizzando vector clocks (o almeno Lamport clocks).

Se si desidera utilizzare un orologio per la sincronizzazione, un orologio logico è più adatto alle proprie esigenze. Eviterete tutti i problemi di sincronizzazione dell'orologio e cose del genere.

Answer 3

Si potrebbe dare un'occhiata a unison. È basato su file ma potresti trovare alcune idee interessanti.