L'uso della cache Redis migliora notevolmente le prestazioni e l'efficienza delle applicazioni, specialmente per la query dei dati. Ma allo stesso tempo, porta anche alcuni problemi. Tra questi, il problema più importante è la coerenza dei dati, che è assolutamente irrisolvibile. Se è richiesta coerenza dei dati, allora non si può utilizzare la cache in cache.
Altri problemi tipici sono la penetrazione della cache, la valanga della cache e la rottura della cache. Attualmente, ci sono anche soluzioni più popolari nel settore. Questo articolo non vuole risolvere questi tre problemi in modo più perfetto, né sovvertire le soluzioni popolari nel settore. Invece, dimostreremo questi tre fenomeni problematici dal funzionamento effettivo del codice. Il motivo di questo è che è difficile avere un concetto molto vivido nella testa solo guardando la spiegazione accademica di questi problemi, e con dimostrazioni reali di codice puoi approfondire la comprensione e la comprensione di questi problemi.
Penetrazione della cache
La penetrazione della cache si riferisce all'interrogazione di dati che non esistono in un database. Se la chiave non esiste o la chiave è scaduta, il database viene interrogato e gli oggetti interrogati vengono inseriti nella cache. Se l'oggetto query del database è vuoto, non viene memorizzato nella cache.
Flusso di codice
- Passano l'ID della chiave primaria dell'oggetto
- Prendi l'oggetto dalla cache basandoti sulla chiave
- Se l'oggetto non è vuoto, restituisce direttamente
- Se l'oggetto è vuoto, esegui una query sul database
- Se l'oggetto interrogato dal database non è vuoto, mettilo nella cache (imposta il tempo di scadenza). Immagina questa situazione, cosa succederebbe se il parametro passato fosse -1? Questo -1 è un oggetto che non deve esistere. Il database verrà interrogato ogni volta, ogni query sarà vuota e non verrà memorizzata nella cache ogni volta. Se si verifica un attacco malevolo, questa vulnerabilità può essere sfruttata per mettere pressione sul database o addirittura sopraffarlo. Anche se viene usato UUID, è facile trovare una CHIAVE inesistente e attaccare.
Nel mio lavoro, uso il metodo di cache dei valori nulli, cioè il passo 5 nel [processo di codice], se l'oggetto interrogato dal database è vuoto, viene anch'esso inserito nella cache, ma il tempo di scadenza della cache impostato è breve, ad esempio impostandolo a 60 secondi.
Valanga di cache
La valanga della cache si riferisce alla scadenza dell'insieme di cache in un certo periodo di tempo.
Uno dei motivi della valanga, ad esempio, è che, mentre scrivo questo articolo, presto saranno le zero del dodicesimo giorno, e presto ci sarà un'ondata di acquisti rapidi. Poi, all'una di notte, il deposito di questo lotto di merci scadrà. La query di accesso per questo lotto di merci ricade sul database, e per il database ci saranno picchi di pressione periodici.
Quando Xiaobian realizza progetti di e-commerce, generalmente adotta diverse categorie di beni e memorizza cicli differenti. Beni della stessa categoria, più un fattore casuale. In questo modo, il tempo di scadenza della cache può essere disperso il più possibile, il tempo di cache dei prodotti nelle categorie popolari è più lungo, mentre il tempo di cache dei prodotti nelle categorie impopolari è più breve, il che può anche far risparmiare le risorse del servizio di cache.
In effetti, la scadenza centralizzata non è molto fatale, e la valanga di cache più fatale è che un nodo del server di cache si blocca o si disconnette. Poiché la valanga di cache che si verifica naturalmente deve essere creata entro un certo periodo di tempo, il database può resistere alla pressione, e in questo momento può anche sopportare la pressione. Non è altro che una pressione periodica sul database. Il tempo di inattività del nodo del servizio cache genera una pressione imprevedibile sul server del database, e probabilmente sovraccaricherà il database in un attimo.
Rottura della cache
La rottura della cache si riferisce a una chiave molto calda, che trasporta costantemente grande concorrenza; la grande concorrenza si concentra sull'accesso a questo punto; quando questa chiave fallisce, la concorrenza continua grande rompe la cache e richiede direttamente il database, proprio come forare un buco in una barriera.
Quando Xiaobian si occupava di progetti di e-commerce, ha reso questo prodotto un "successo".
In effetti, nella maggior parte dei casi, questo tipo di esplosione è difficile da mettere sotto pressione schiacciante il server del database. Sono poche le aziende che hanno raggiunto questo livello. Pertanto, l'editor pragmatico si è preparato per i prodotti principali in anticipo, così che la cache non scada mai. Anche se alcuni prodotti fermentano da soli fino a diventare bofi, possono essere impostati come mai in scadenza.
La strada principale è semplice, e la serratura di rifiuto mutuo della chiave mutex non viene davvero utilizzata.
|
Pubblicato su 19/11/2019 09:55:04
|
|
|
|
