Ciao a tutti! Sono Jayon.

Oggi vi spiegherò i criteri per la configurazione della cache. Questo post è basato sulla mia esperienza pratica, quindi è solo un riferimento. ㅎㅎ

Cos'è la cache?

La cache è un modo per fornire rapidamente i risultati di una richiesta futura memorizzandoli in anticipo. In altre parole, si tratta di memorizzare i risultati in anticipo e quando viene effettuata una richiesta, invece di accedere al DB o all'API, si accede alla cache per elaborare la richiesta. Lo sfondo di questa cache è la legge di Pareto.

La legge di Pareto afferma che l'80% dei risultati è causato dal 20% delle cause, quindi potresti voler dare un'occhiata all'immagine qui sotto!

In altre parole, non è necessario memorizzare nella cache tutti i risultati, ma memorizzare nella cache solo il 20% più utilizzato durante il servizio può aumentare l'efficienza complessiva.

Quali dati memorizzare nella cache?

Secondo la legge di Pareto, non dovresti memorizzare nella cache tutti i dati, ma solo i dati più necessari. Quindi, quali dati dovresti memorizzare nella cache?

Dati che devono essere letti frequentemente ma raramente scritti

In teoria, si dice spesso che "è necessario memorizzare nella cache i dati che devono essere letti frequentemente ma raramente scritti", ma i criteri per "lettura frequente" e "scrittura rara" sono stati piuttosto ambigui.

Pertanto, esamino i dati da memorizzare nella cache seguendo i passaggi seguenti.

• Controllare le prime 5 voci di cronologia delle chiamate RDB tramite APM come DataDog.
• Tra queste, cercare le query di ricerca e verificare da quale tabella vengono recuperate.
• Verificare quante volte viene eseguita la query di aggiornamento per la tabella corrispondente.

Questo processo è per vedere se vengono eseguite molte query di ricerca ma le query di aggiornamento sono poche. La tabella che ho verificato sul campo ha eseguito 1.740.000 query di ricerca al giorno, ma le query di aggiornamento sono state circa 500 al massimo. In questo caso, si potrebbe dire che è adatto per la cache, giusto? ㅎㅎ

Dati sensibili alle modifiche

I dati sensibili alle modifiche significano che la discrepanza tra RDB e la cache deve essere breve. Ad esempio, le informazioni relative ai pagamenti sono molto sensibili alle modifiche, quindi anche se soddisfano le condizioni di cache di cui sopra, è necessario valutare se applicarle.

Ho dovuto memorizzare nella cache una tabella relativa ai pagamenti che soddisfaceva le due caratteristiche di cui sopra. Pertanto, non ho applicato la cache a tutta la logica che utilizza la tabella relativa ai pagamenti, ma ho deciso di applicare la cache parzialmente alla logica relativamente sicura in cui il pagamento non si verifica effettivamente.

Cache locale vs cache globale

Ora che abbiamo definito i dati e l'ambito della cache, dobbiamo decidere "dove" memorizzare i dati della cache. Generalmente, puoi memorizzare nella cache nella memoria locale o in un server separato come Redis.

Cache locale

La cache locale è un metodo per memorizzare i dati della cache nella memoria del server dell'applicazione e spesso si utilizzano Guava cache o Caffeine cache.

Vantaggi

• Poiché si accede alla cache nella memoria dello stesso server durante l'esecuzione della logica dell'applicazione, la velocità è elevata.
• È facile da implementare.

Svantaggi

• Se ci sono più istanze, si verificano diversi problemi.
  • È impossibile propagare la cache modificata da un'istanza a un'altra. Tuttavia, esistono librerie di cache locali che propagano le modifiche ad altre istanze.
  • Poiché la cache viene memorizzata in ogni istanza, se viene creata una nuova istanza, è necessario inserire nuovamente la cache. Ciò può causare molti errori di cache e l'istanza potrebbe non essere in grado di gestire il traffico e morire.

Cache globale

La cache globale è un metodo che utilizza un server separato come Redis per memorizzare i dati della cache.

Vantaggi

• Poiché la cache viene condivisa tra le istanze, anche se la cache viene modificata in un'istanza, tutte le istanze possono ottenere lo stesso valore della cache.
• Anche se viene creata una nuova istanza, è sufficiente guardare al repository di cache esistente, quindi non è necessario eseguire l'operazione di riempimento della cache.

Svantaggi

• È necessario passare attraverso il traffico di rete, quindi la velocità è inferiore rispetto alla cache locale.
• È necessario utilizzare un server di cache separato, quindi si verificano costi di gestione dell'infrastruttura.
  • Costi di gestione dell'infrastruttura? → Costi del server, tempo per la configurazione e la manutenzione dell'infrastruttura, piano di risposta agli errori, ecc.

Cosa ho scelto?

Attualmente, il server dell'applicazione della mia azienda è strutturato in modo da eseguire più istanze, ma ho scelto la cache locale.

Ci sono tre motivi principali.

• I dati da memorizzare nella cache memorizzati in RDB sono circa 40.000, quindi anche se vengono tutti caricati nella memoria, sono inferiori a 4 MB.
• Era necessario migliorare le prestazioni di ricerca dei dati relativi ai pagamenti.
• Anche se Redis è già disponibile, la memorizzazione nella cache dei nuovi dati in Redis comporterà costi di infrastruttura.

Come aggiornare la cache?

Se ci sono più server di applicazione e la cache locale è applicata a questi, il valore della cache memorizzato in ogni server di applicazione potrebbe essere diverso. Ad esempio, il dato della cache memorizzato nel server A è "1", ma il dato della cache memorizzato nel server B potrebbe essere "2" se viene modificato dal server B. In questa situazione, se un utente invia una richiesta al bilanciamento del carico, riceverà valori diversi dal server A e dal server B.

Pertanto, è necessario configurare l'eliminazione automatica della cache per ogni istanza in modo che venga recuperata da RDB e, in questo caso, viene spesso utilizzato il TTL.

Qual è il TTL da impostare?

TTL sta per Time To Live ed è un'impostazione per eliminare la cache dopo un certo periodo di tempo. Ad esempio, se il TTL è impostato su 5 secondi, i dati della cache verranno eliminati automaticamente dopo 5 secondi. Successivamente, se si verifica un errore di cache, i dati verranno recuperati da RDB e memorizzati.

Quindi, qual è il TTL da impostare?

Lettura/scrittura che si verifica in un singolo server di cache

Se la lettura/scrittura si verifica in un singolo server di cache globale come Redis o in un singolo server di applicazione a cui è applicata la cache locale, è possibile aumentare il valore del TTL oltre l'unità di tempo. In ogni caso, la cache verrà modificata durante la scrittura e il server che recupera i dati da quella cache vedrà sempre i dati aggiornati.

In questo caso, non è necessario impostare il TTL e la cache può essere configurata in modo che venga svuotata automaticamente a poco a poco utilizzando l'algoritmo LRU quando il server di cache è pieno.

Lettura/scrittura che si verifica su più server di cache

Se la lettura/scrittura si verifica su più server di cache globali o su più server di applicazione a cui è applicata la cache locale, è meglio impostare il TTL su unità di secondi o minuti. Questo perché c'è la possibilità di leggere dati vecchi di un server di cache che non ha ancora applicato i dati modificati.

In questo caso, il TTL è determinato da una varietà di contesti e più la modifica è importante e più è alta la probabilità di modifica del valore, più breve dovrebbe essere il TTL, mentre meno è importante la modifica e meno è alta la probabilità di modifica del valore, più lungo può essere il TTL.

Come ho impostato il TTL?

I dati che memorizzo nella cache sono correlati ai pagamenti e anche se non applico la cache alla logica stretta in cui si verifica effettivamente il pagamento, la modifica è comunque importante a causa della natura dei pagamenti. Tuttavia, poiché la probabilità di aggiornamento è bassa, ho impostato il TTL su circa 5 secondi per sicurezza.

Conclusione

Riassumendo, il metodo di memorizzazione nella cache che ho scelto è il seguente.

• Dati relativi ai pagamenti
• La ricerca viene eseguita molto frequentemente, ma la modifica è rara.
• La cache viene applicata alla logica in cui si verifica la ricerca, ma non si verifica effettivamente il pagamento.
• È stata applicata la cache locale e il TTL è stato impostato su 5 secondi.

Il prossimo passo è eseguire un test di prestazioni sul metodo di memorizzazione nella cache effettivamente applicato. Sto ancora pensando a come eseguire il test di prestazioni in dettaglio, quindi lo scriverò in un post futuro!