In che modo Redis (o qualsiasi tipica cache distribuita) gestisce i conflitti di replica?

Question

In che modo Redis (o qualsiasi tipica cache distribuita) gestisce i conflitti di replica?

#1 da (1 voti)

3

Supponiamo di aver impostato un cluster Redis con un master e due slave. Due client sono collegati a ciascuno degli schiavi. Entrambi i client apportano modifiche in conflitto allo stesso tempo:

Cosa succede se queste modifiche vengono replicate su Master nello stesso momento? Vengono semplicemente applicati al Master nell'ordine in cui vengono ricevuti, quindi replicati di nuovo?

Cosa succede se le transazioni vengono utilizzate? Il risultato alla fine è coerente, cioè Master risolve il conflitto applicando le transazioni in un certo ordine, quindi replica la risoluzione verso il basso?

Non mi aspetto una consistenza perfetta da una cache distribuita, ma voglio capire i punti fini in modo che io usi bene la cache. L'applicazione su cui sto lavorando utilizza la cache distribuita per il coordinamento tra thread / processi dell'operatore. Ad esempio, quando un lavoratore elabora un elemento, inserisce una chiave nella cache con una scadenza di 1 minuto che comunica agli altri lavoratori di non elaborare lo stesso articolo. È accettabile se due o tre lavoratori finiscono per elaborare lo stesso oggetto, ma questo meccanismo impedisce una rielaborazione infinita.

caching redis distributed-system

posta Joey Adams 04.01.2017 - 22:11

fonte

1 risposta

Leggi altre domande sui tag caching redis distributed-system

Come eseguire il data mining in modo efficiente (in PHP)? Passa il risultato nel concatenamento API

score 1 · Answer 1

Chiedo scusa per non aver saputo i nomi ufficiali o reali. La mia speranza è che qualcuno arrivi e modifica la mia risposta con i nomi appropriati.

Ci sono poche opzioni:

L'ultimo è il migliore - si presume che l'ultimo sia il cache più corretto. Tutto il resto è obsoleto o sbagliato. Questo funziona fintanto che tutti i sistemi hanno i loro orologi sincronizzati. Inoltre, si noti che il loro è ancora un criterio utilizzato qui (di essere l'ultimo) e tutto il resto fa la stessa cosa, utilizzando un criterio diverso.
Regole principali - C'è un maestro eletto (ci sono una miriade di algos solo per le elezioni dei leader che sto saltando per mantenere le cose brevi). Ogni client esegue il check in con il master e copia semplicemente sulla cache se non sincronizzato. Alcuni sistemi non si preoccupano nemmeno di controllare e sovrascrivono semplicemente ciecamente la propria cache con la versione del master. Quando il master fallisce, le cose si complicano.
Consenso: ogni computer conosce tutti gli altri computer nella rete. Periodicamente, uno dei sistemi richiede un controllo del consenso e tutti trasmettono lo stato della cache. Ogni computer decide autonomamente quale cache è l'ultima basata su un algoritmo predefinito. Le cose si divertono quando alcuni nodi in particolare collegano in rete le connessioni con pochi altri (ma non tutti).
Consenso parziale - Come il consenso, ma tende a essere lassista nei suoi calcoli. Questo è utile quando i nodi continuano a venire e amp; andando verso il basso casualmente (istanze di AWS Spot) e stai bene con le cache alla fine coerenti.
Nessun conflitto - Il computer presume che non ci possa essere conflitto. Qualunque cosa abbia è corretta e tutti gli altri vanno all'inferno. Questa è una cattiva idea non appena hai più di un nodo.