Le migliori pratiche per mantenere sincronizzate origini dati diverse?

Question

Le migliori pratiche per mantenere sincronizzate origini dati diverse?

#1 da (2 voti)
#2 da (0 voti)

2

Ho dei dubbi su come implementare e mantenere la sincronizzazione tra due origini dati in un sistema distribuito. Nel mio caso, ho un servizio che controlla i lavori scaduti in un repository. Se il lavoro è scaduto, viene rimosso dal repository e accodato in una coda distribuita (l'esempio è in Python ma dovrebbe essere facile da capire):

def check_expired_jobs(self):
    jobs = self._job_repository.all()

    for job in [ job for job in jobs if job.has_expired() ]:
        self._job_queue.enqueue(job.crawl_task)
        self._job_repository.delete(job)

Le mie preoccupazioni sono che possono succedere molte cose da quando sia la coda che il repository sono fonti di dati remote. Se l'operazione della coda ha esito positivo, ma per qualsiasi motivo l'eliminazione del repository non riesce, potrei incorrere in un problema di incoerenza. Non è la prima volta che incontro un problema del genere e voglio affrontarlo nel miglior modo possibile.

Quale sarebbe la migliore prassi per mantenere sincronizzate più fonti / repository di dati?

repository synchronization

posta David Jiménez Martínez 22.08.2017 - 12:41

fonte

2 risposte

0

In questo caso, l'utilizzo di una transazione risolverebbe il tuo problema. Con questo non intendo una transazione di database, ma un modello di transazione, se lo vorrai.

Non ho mai scritto alcun codice in Python, quindi non so se Python abbia un costrutto Transaction di qualche tipo. Tuttavia, in questo caso, sarebbe abbastanza facile trovare qualcosa da solo.

Fondamentalmente quello che faresti è accodare il lavoro e poi provare ad eliminare il lavoro. Se la cancellazione non riesce, devi eseguire il rollback della "transazione", che nel tuo caso significa rimuovere il lavoro dalla coda se tale passaggio è stato completato.

Per fare ciò, è necessario un po 'di archiviazione locale dello stato Transactions, finché non viene eseguito il commit (perché la cancellazione è avvenuta con successo) o il rollback (perché l'eliminazione non è riuscita e la rimozione del lavoro dalla coda ha funzionato). Lo stato includerebbe l'attività completa o un modo per recuperare l'attività.

risposta data 22.08.2017 - 15:28

fonte

Leggi altre domande sui tag repository synchronization

Presa su un server web Come automatizzare determinate attività in un'applicazione web?

score 2 · Accepted Answer

If the queue operation is successful but for whatever reason the repository deletion fails I could run into an inconsistency issue.

La soluzione più semplice in questo caso è solo non renderlo un problema . Stai progettando questa cosa, giusto?

Hai solo bisogno di scrivere qualsiasi programma che legge il repository per trattare i record scaduti come se non esistessero. Questo è in realtà la chiave per qualsiasi tipo di tolleranza agli errori - è necessario consentire alla coda di crescere e ridursi (anche un po ') in qualsiasi ragionevole tipo di tolleranza ai guasti - quindi è necessario fare comunque una regola, se non l'hai fatto Puoi farlo con una vista se non vuoi inquinare il tuo codice c #.

Quindi, in un processo separato, copia occasionalmente (non spostare) i record scaduti nella coda distribuita. Se la copia fallisce, diamine, prova a copiarli nuovamente alcuni secondi o pochi minuti dopo. Dico "copia, non spostare", perché al repository non dovrebbe importare se esiste un record scaduto o meno.

Naturalmente finirai per esaurire lo spazio su disco con i record scaduti. Quindi è necessario anche un lavoro semplice, in esecuzione forse una volta ogni 24 ore, per eliminare fisicamente i record scaduti, se e solo se esistono da qualche parte nella coda distribuita. Puoi abbreviare se hai bisogno di prestazioni elevate. Puoi persino farlo immediatamente ogni volta che aggiungi alla coda distribuita.

L'unica difficoltà è in realtà garantire che la copia dei record scaduti non comporti duplicati nel sistema di code distribuite. È possibile eseguire ciò in modo molto semplice taggando ogni lavoro con un GUID e applicando un vincolo di unicità. Molto semplice per un database che lavora in isolamento.

Non scimmiottare con 2PC a meno che non lo faccia per auto-educazione. Date le vostre esigenze è un modo eccessivo.

Best practice to keep different data sources in sync?

La best practice è KISS .