Le applicazioni Web moderne funzionano con enormi quantità di dati archiviati nei database back-end. Quindi, quelle applicazioni Web che funzionano con i dati dovrebbero essere attentamente ottimizzate per le prestazioni. Ogni richiesta presentata su una rete a un database è costosa. D'altra parte, influisce direttamente sulle prestazioni di un'applicazione Web.

La memorizzazione nella cache sul lato client consente di archiviare i dati frequentemente accessibili all'estremità del browser o nella memoria del server delle applicazioni. Consuma in una certa misura l'archiviazione sul lato client, ma il guadagno delle prestazioni è alto. Di solito, quando sono richiesti i dati, il client invia una richiesta al back -end per eseguire la query dati. Il più delle volte, i client Web recuperano lo stesso set di dati più e più volte dal database. Con la memorizzazione nella cache lato client, i dati recuperati tramite query popolari sono archiviati sul lato client.

La memorizzazione nella cache sul lato cliente ha due vantaggi principali:

• Migliora le prestazioni di un importo considerevole.
• Riduce il database e i carichi di rete.

Allo stesso tempo, la memorizzazione nella cache sul lato client affronta la sfida di mantenere i dati aggiornati. Se i dati vengono modificati nella fine del database, quel pezzo di dati nella cache del client viene obsoleto e il client deve essere avvisato immediatamente per recuperare il pezzo aggiornato. Redis ha implementato il suo modello di memorizzazione nella cache affrontando questi problemi.

Imposta la memorizzazione nella cache sul lato client con Redis

In Redis, la memorizzazione nella cache sul lato client è nominata Tracciamento. Esistono due modalità di tracciamento supportate da Redis. La modalità predefinita si chiama tracciamento assistito dal server, in cui il server invia notifiche di invalidazione correlate solo alle chiavi che si trovano nella cache client. D'altra parte, la modalità di trasmissione offre ai clienti la libertà di iscriversi ai prefissi chiave preferiti e ricevere notifiche ogni volta che viene modificata una chiave con il prefisso abbonato.

Tracciamento assistito dal server per i client Redis

Come suggerisce il nome, in modalità assistita dal server, il server tiene traccia delle chiavi a cui un client specifico sta accedendo. Ogni volta che una chiave tracciata viene modificata nel database, il client verrà avvisato immediatamente. Ancora più importante, le notifiche di invalidazione sono generate solo per le chiavi che si trovano in una determinata cache del client. L'unico aspetto negativo di questa modalità è che sfrutta la memoria del server per ricordare le chiavi accessibili da parte di ciascun client.

Cliente dedicato per le notifiche di invalidazione

Di solito, la memorizzazione nella cache sul lato client assistito dal server viene implementata utilizzando un client dedicato che riceve notifiche di invalidazione. Questo client è il punto centrale che riceve tutti i messaggi di invalidazione per tutti i client connessi a un determinato database.

Impostiamo un client dedicato per ricevere messaggi di invalidazione. Innanzitutto, dobbiamo connetterci al nostro server Redis come client autorizzato e ottenere l'ID del client come segue.

Identificativo cliente

Il comando sopra restituisce l'ID della connessione client corrente, che è 3. Questo ID è necessario nei passaggi successivi per identificarlo come client centrale per ricevere i messaggi di invalidazione. Successivamente, ci iscriviamo al canale di notifica di invalida come segue. È possibile utilizzare il comando di iscrizione.

Iscriviti al canale [canale ...]

In questo esempio, il canale è __redis __: invalidare.

Iscriviti __redis __: invalidare

Ora abbiamo impostato la connessione client per ricevere le notifiche di invalidazione. Iniziamo un'altra connessione client e attiviamo il monitoraggio del client. Inoltre, reindirizza tutti i messaggi di invalidazione associati al nuovo client al client centrale creato nel passaggio precedente. Possiamo utilizzare il comando di tracciamento client per raggiungere questo obiettivo. Quanto segue è la sintassi del comando di tracciamento client.

Tracciamento del cliente [Reindirizzamento client-id] [prefisso prefisso [prefisso prefisso ...]] [bcast] [optin] [optout] [NOLOOP]

Su | SPENTO : Determinare se il monitoraggio del client deve essere abilitato o meno.

REINDIRIZZARE : Specificare l'ID del client che riceve messaggi di invalidazione.

Abilitiamo il monitoraggio del client per un nuovo client autorizzato e utilizziamo l'opzione reindirizzamento per specificare la connessione che riceve l'invalidazione, messaggi 3 che sono 3.

Tracciamento del client su reindirizzamento 3

Ora siamo pronti a testare il monitoraggio del nostro cliente Redis. Innanzitutto, impostiamo una coppia di valore chiave come segue.

Imposta il nome utente "user_01"

Successivamente, accediamo al nome utente dallo stesso client, che memorizzerà nella cache di tale informazione sul lato client poiché abbiamo abilitato il monitoraggio del client.

Ottieni nome utente

Apriamo un nuovo client e modificiamo il valore memorizzato nella chiave nome utente come segue.

Imposta il nome utente "user_2"

Immediatamente, il cliente che si è iscritto al canale invalidato viene informato che il valore memorizzato nella chiave nome utente è stato modificato ed è già valido.

Questo modello si basa sul protocollo RESP2, che è il protocollo predefinito che i client Redis utilizzano.

Protocollo RESP3 per ricevere notifiche al client di tracciamento

Dalla versione 6.0, Redis introduce il protocollo RESP3, che consente a un client attivo di ricevere messaggi di invalidazione. Questo è un enorme vantaggio in cui un client Redis può ascoltare un determinato canale durante l'emissione di comandi.

Controlliamo prima la versione Redis. Deve essere la versione 6.0 o l'ultimo a utilizzare il protocollo RESP3. È possibile emettere il seguente comando per verificare la versione Redis.

Redis-cli -Version

Dal momento che è la versione 7.0, siamo tutti bravi a usare il protocollo RESP3. I client Redis usano RESP2 per impostazione predefinita. Quindi, dobbiamo passare al protocollo RESP3.

Ciao 3

Ciò cambierebbe il protocollo in RESP3 con il seguente output.

Abilitiamo il monitoraggio del client come nell'esempio precedente utilizzando il comando di tracciamento client. In questo caso, non è necessario specificare l'opzione di reindirizzamento.

Tracciamento del cliente

Ora le chiavi che questo client recupera verrà monitorato dal server. Inoltre, quando il valore di una chiave monitorata modifica, un messaggio di invalidazione verrà inviato ai clienti che hanno memorizzato la cache di quella particolare chiave.

Prendiamo la chiave nome utente.

Ottieni nome utente

Il cliente cade il file nome utente chiave e valore associato. Ora, avviamo un'altra connessione client e cambiamo il valore memorizzato nella chiave nome utente.

Se si controlla la connessione client precedente, non è stato ancora ricevuto alcun messaggio di invalidazione. Se si emette un altro comando, la notifica di invalidazione verrà visualizzata immediatamente come segue.

2. Modalità di trasmissione per il monitoraggio del client

Nella modalità predefinita, i clienti ricevono notifiche di invalidazione solo per le chiavi che hanno preso nelle precedenti chiamate di comando. Con la modalità di trasmissione abilitata, i client si iscrivono a un prefisso chiave specifico e il client riceve notifiche di invalidazione per ogni chiave che viene modificata la cui chiave inizia con il prefisso abbonato.

Utilizziamo una nuova connessione client per ricevere i messaggi di invalidazione iscrivendoci al canale invalidato come segue.

In questo esempio, l'ID connessione client è 10, che verrà utilizzato con l'opzione di reindirizzamento per un nuovo client. Specifichiamo l'opzione Bcast nel comando di tracciamento client come segue.

Tracciamento client su Bcast Prefisso Utente: Reindirizzarsi 10

Supponiamo che abbiamo una chiave chiamata Utente: ID: 1 nell'istanza Redis. Prendiamolo da questo cliente.

Ora l'utente: ID: 1 chiave è memorizzata nella cache sul lato client.

Creiamo una nuova connessione client e impostiamo una nuova chiave come segue: Utente: ID: 3.

In questo momento, il client che ha abilitato il monitoraggio riceve un messaggio di invalidazione e verrà reindirizzato al client identificato dall'ID 10. Questo accade perché la nuova chiave contiene il prefisso utente: che è il prefisso abbonato dal client abilitato di tracciamento. Come puoi vedere, il server non tiene traccia di nessuna delle chiavi che ogni client recupera, ma trasmette messaggi di invalidazione se il prefisso chiave modificato corrisponde al prefisso abbonato da ciascun client.

Opzioni optin e optout

Le opzioni Optin e Optout possono essere utilizzate per filtrare quali chiavi il server dovrebbe tracciare esattamente o no. Con queste opzioni abilitate nel comando di tracciamento client, Redis tiene solo traccia delle chiavi che sono query subito dopo il comando del client cache SÌ. Ciò riduce al minimo l'utilizzo della memoria lato server e si carica drasticamente.

Conclusione

In sintesi, la memorizzazione nella cache sul lato client è una delle tecniche ampiamente utilizzate per migliorare le prestazioni delle applicazioni Web che richiedono frequentemente dati da database back-end. Come discusso, il browser o il server delle applicazioni sul lato client possono contenere i dati relativi alle query popolari emesse dal client. Come menzionato nell'introduzione, in Redis, la memorizzazione nella cache sul lato client si chiama Tracking. Inoltre, le due modalità di tracciamento sono disponibili in Redis. Entrambe le modalità client dedicate e di trasmissione hanno i propri casi d'uso.