Possibilità di dati obsoleti nel modello di cache-aside

Question

Possibilità di dati obsoleti nel modello di cache-aside

Naviga le tue risposte

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

4

Solo per re-cape pattern di cache-aside definisce i seguenti passaggi durante il recupero e l'aggiornamento dei dati.

Recupero elemento

Restituisce l'oggetto dalla cache se trovato in esso.
Se non si trova nella cache, leggi dall'archivio dati.
Metti l'elemento letto nella cache e restituiscilo.

Aggiornamento elemento

Scrivi l'elemento nell'archivio dati.
Rimuovi la voce corrispondente dalla cache.

Funziona perfettamente in quasi tutti i casi, ma sembra fallire in uno scenario teorico.

Che cosa succede se il passaggio 1 & 2 di elemento di aggiornamento , si verificano tra il punto 2 e il punto 3 di elemento di recupero . In altre parole, considera che inizialmente il data store avesse il valore 'A' e non fosse nella cache. Quindi, quando recuperiamo l'oggetto, leggiamo "A" dall'archivio dati, ma prima di mettere nella cache, l'elemento è stato aggiornato a "B" in un altro thread (quindi "B" è stato scritto nell'archivio dati e ha cercato di rimuovere la voce dalla cache , che non era lì in quel momento). Ora, quando il thread di recupero inserisce l'elemento nella cache (cioè "A"). Quindi ora 'A' rimarrà memorizzato nella cache e ulteriori recuperi restituiranno dati non aggiornati, fino a quando l'elemento non scade o viene aggiornato di nuovo.

Quindi mi manca qualcosa qui, la mia comprensione del modello è sbagliata. O che lo scenario è praticamente impossibile, e non c'è bisogno di preoccuparsene.

Inoltre vorrei sapere se è possibile apportare alcune modifiche nel modello per evitare questo problema.

design-patterns concurrency caching memcached

posta Ammar 19.10.2016 - 10:41

fonte

2 risposte

Leggi altre domande sui tag design-patterns concurrency caching memcached

Usando un piccolo numero di classi da una grande libreria C'è qualche buona ragione per cui i classvari Python e l'ereditarietà del prototipo di JavaScript non mutano il genitore al momento dell'assegnazione?

score 6 · Answer 1

Stai indicando correttamente una condizione di gara.

Cache-aside, come descritto qui e qui , è un'astrazione imperfetta che non è appropriata per tutti i casi di utilizzo di archiviazione dei dati.

Consistency. Implementing the Cache-Aside pattern does not guarantee consistency between the data store and the cache. An item in the data store may be changed at any time by an external process, and this change might not be reflected in the cache until the next time the item is loaded into the cache. In a system that replicates data across data stores, this problem may become especially acute if synchronization occurs very frequently.

Questo testo fa riferimento ai problemi quando qualcuno modifica l'archivio dati senza informare la cache della necessità di invalidare. (Il modello descrive la necessità di una politica di sgombero appropriata, che è intesa a limitare la durata degli errori di dati.)

Tuttavia, le condizioni della gara che stai indicando potrebbero verificarsi anche se tutti i clienti stanno giocando secondo le regole. Quando si verifica la condizione della competizione, i dati non aggiornati verranno depositati nella cache e rimarranno lì fino a quando non saranno sfrattati (per lo sfratto standard (es. Basato sul tempo) o perché i dati di quel tasto saranno nuovamente aggiornati, e questa volta forse senza la gara .)

Fornire dati obsoleti insieme a dati aggiornati è un tipo peggiore di violazione della coerenza rispetto alla semplice restituzione di informazioni non aggiornate che erano almeno completamente corrette prese insieme in un determinato momento (un'istantanea). Talvolta viene chiamato una forma di inclinazione di lettura o scrittura.

Also I would like to know if some changes can be made in the pattern to avoid this problem.

Un problema con questo modello è che si diffonde un'unica responsabilità (archiviazione dei dati, stato di conservazione) tra più componenti. Quindi, un modo per correggere le condizioni di gara che stai segnalando è di cambiare il modello in modo che la cache sia un'entità di prima classe che ha la piena responsabilità sia per la lettura che per la scrittura dei dati. I client chiedono dati alla cache, la cache, quando necessario, recupera i dati dall'archivio dati e li restituisce ai client. I client informerebbero la cache degli aggiornamenti e la cache aggiornerebbe l'archivio dati. La cache sarebbe quindi in grado di fornire la sincronizzazione appropriata in modo da evitare le condizioni di gara.

In definitiva, questo modello è utile per i dati che non cambiano spesso e per la memorizzazione dei dati che non dipende dalla consistenza / transazioni impostate su più chiavi. Ad esempio, potrebbe funzionare per alcuni tipi di archivi di documenti, come una libreria musicale, soprattutto se la libreria è in gran parte aggiunta, le chiavi non vengono mai aggiornate e occasionalmente i documenti vengono cancellati ma è ok (dal punto di vista commerciale) per continuare per servirli per la durata di sfratto dopo che sono stati cancellati.

score 0 · Answer 2

What if step 1 & 2 of updating item, happen between step 2 & 3 of fetching item

Questo problema viene evitato se il recupero dell'elemento e l'aggiornamento dell'elemento possono essere considerati operazioni atomiche l'una rispetto all'altra. I due processi vengono quindi chiamati sincronizzati .

Il modo in cui questo può essere realizzato (in modo efficiente e idiomatico) dipende dal linguaggio di implementazione.