Les applications Web modernes fonctionnent avec des quantités massives de données stockées dans des bases de données back-end. Ainsi, les applications Web qui fonctionnent avec les données doivent être soigneusement optimisées pour les performances. Chaque demande faite sur un réseau dans une base de données est coûteuse. D'un autre côté, il affecte directement les performances d'une application Web.

La mise en cache côté client permet de stocker des données fréquemment consultées à la fin du navigateur ou dans la mémoire du serveur d'applications. Il consomme un stockage côté client dans une certaine mesure, mais le gain de performance est élevé. Habituellement, lorsque les données sont requises, le client envoie une demande à l'arrière des données de requête. La plupart du temps, les clients Web récupèrent le même ensemble de données encore et encore à partir de la base de données. Avec la mise en cache côté client activé, les données récupérées via des requêtes populaires sont stockées du côté client.

La mise en cache côté client a deux principaux avantages:

• Améliore les performances d'un montant considérable.
• Réduit la base de données et les charges réseau.

Dans le même temps, la mise en cache côté client fait face au défi de suivre les données à jour. Si les données sont modifiées dans l'extrémité de la base de données, ce morceau de données dans le cache client devient obsolète et le client doit être informé immédiatement pour récupérer la pièce mise à jour. Redis a mis en œuvre son modèle de mise en cache en résolvant ces problèmes.

Configurer la mise en cache côté client avec redis

Dans Redis, la mise en cache côté client est nommée suivi. Il y a deux modes de suivi pris en charge par redis. Le mode par défaut est appelé suivi assisté par le serveur, où le serveur envoie des notifications d'invalidation qui ne sont liées qu'aux touches qui se trouvent dans le cache client. D'un autre côté, le mode de radiodiffusion donne aux clients la liberté de s'abonner aux préfixes de clés préférés et de recevoir des notifications chaque fois qu'une clé avec le préfixe abonné est modifiée.

Suivi assisté par le serveur pour les clients redis

Comme son nom l'indique, en mode assisté par serveur, le serveur garde une trace des clés à laquelle un client spécifique accède. Chaque fois qu'une clé suivie est modifiée dans la base de données, le client sera immédiatement informé. Plus important encore, les notifications d'invalidation sont générées uniquement pour les clés qui sont dans un cache client donné. Le seul inconvénient de ce mode est qu'il exploite la mémoire du serveur pour se souvenir des touches accessibles par chaque client.

Client dédié aux notifications d'invalidation

Habituellement, la mise en cache côté client assisté par le serveur est implémentée à l'aide d'un client dédié qui reçoit des notifications d'invalidation. Ce client est le point central qui reçoit tous les messages d'invalidation pour tous les clients connectés à une base de données donnée.

Confirons un client dédié pour recevoir des messages d'invalidation. Tout d'abord, nous devons nous connecter à notre serveur Redis en tant que client autorisé et obtenir l'ID du client comme suit.

identité du client

La commande ci-dessus renvoie l'ID de la connexion client actuelle, qui est 3. Cet identifiant est nécessaire dans les prochaines étapes pour l'identifier comme le client central pour recevoir les messages d'invalidation. Ensuite, nous souscrivons au canal de notification d'invalidation comme suit. La commande abonné peut être utilisée.

Abonner canal [canal…]

Dans cet exemple, le canal est __redis __: invalider.

abonner __redis __: invalider

Maintenant, nous avons configuré la connexion client pour recevoir les notifications d'invalidation. Laissons une autre connexion du client et activons le suivi du client. De plus, nous redirigeons tous les messages d'invalidation associés au nouveau client vers le client central créé à l'étape précédente. Nous pouvons utiliser la commande de suivi client pour y parvenir. Ce qui suit est la syntaxe de la commande de suivi client.

Suivi des clients [Redirection Client-ID] [Prefix Prefix [Prefix Prefix…]] [BCAST] [Optin] [Optout] [Noloop]

Sur | DÉSACTIVÉ : Déterminez si le suivi des clients doit être activé ou non.

Redirection: Spécifiez l'ID du client qui reçoit des messages d'invalidation.

Activons le suivi du client pour un nouveau client autorisé et utilisons l'option de redirection pour spécifier la connexion qui reçoit l'invalidation, messages qui est 3.

Suivi du client sur la redirection 3

Maintenant, nous sommes prêts à tester notre suivi du client redis. Tout d'abord, nous définissons une paire de valeurs clés comme suit.

Définir le nom d'utilisateur "user_01"

Ensuite, nous accédons au nom d'utilisateur à partir du même client, qui mettra en cache cette information du côté client, car nous avons permis le suivi client.

Obtenez le nom d'utilisateur

Ouvrez un nouveau client et modifions la valeur stockée dans la clé nom d'utilisateur comme suit.

Définir le nom d'utilisateur "user_2"

Immédiatement, le client qui s'est abonné au canal invalidate est informé que la valeur stockée à la clé nom d'utilisateur a été modifié et il est déjà invalide.

Ce modèle est basé sur le protocole REP2, qui est le protocole par défaut que les clients redis utilisent.

Protocole resp3 pour recevoir des notifications au client de suivi

De la version 6.0, Redis présente le protocole REP3, qui permet à un client actif de recevoir des messages d'invalidation. C'est un énorme avantage où un client Redis peut écouter une chaîne donnée tout en émettant des commandes.

Vérifions d'abord la version redis. Ce doit être la version 6.0 ou le dernier à utiliser le protocole REP3. La commande suivante peut être émise pour vérifier la version redis.

Redis-Cli --version

Puisque c'est la version 7.0, nous sommes tous bons à utiliser le protocole REP3. Les clients redis utilisent REP2 par défaut. Nous devons donc passer au protocole REP3.

Bonjour 3

Cela changerait le protocole en resp3 avec la sortie suivante.

Activons le suivi du client comme dans l'exemple précédent en utilisant la commande de suivi du client. Dans ce cas, nous n'avons pas besoin de spécifier l'option de redirection.

Suivi des clients sur

Maintenant, les clés que ce client obtient sera suivie par le serveur. De plus, lorsque la valeur d'une clé suivie change, un message d'invalidation sera envoyé aux clients qui ont mis en cache cette clé particulière.

Reprenons la clé nom d'utilisateur.

Obtenez le nom d'utilisateur

Le client cache le nom d'utilisateur clé et sa valeur associée. Maintenant, nous initions une autre connexion client et modifions la valeur stockée dans la clé nom d'utilisateur.

Si vous vérifiez la connexion du client précédent, aucun message d'invalidation n'est encore reçu. Si vous émettez une autre commande, la notification d'invalidation sera affichée immédiatement comme suit.

2. Mode de diffusion pour le suivi des clients

Dans le mode par défaut, les clients obtiennent des notifications d'invalidation uniquement pour les clés qu'ils ont récupérées dans les appels de commande antérieurs. Avec le mode de diffusion activé, les clients s'abonnent à un préfixe de clé spécifique et le client obtient des notifications d'invalidation pour chaque clé qui est modifiée dont la clé commence par le préfixe abonné.

Utilisons une nouvelle connexion client pour recevoir les messages d'invalidation en abonnement au canal invalidate comme suit.

Dans cet exemple, l'ID de connexion client est de 10, qui sera utilisé avec l'option de redirection pour un nouveau client. Spécions l'option BCAST dans la commande de suivi client comme suit.

Suivi du client sur l'utilisateur du préfixe BCast: rediriger 10

Supposons que nous avons une clé appelée utilisateur: id: 1 dans l'instance redis. Profitons-le de ce client.

Maintenant, l'utilisateur: ID: 1 La clé est mise en cache du côté client.

Créons une nouvelle connexion client et définissons une nouvelle clé comme suit: Utilisateur: ID: 3.

En ce moment, le client qui a permis le suivi reçoit un message d'invalidation, et il sera redirigé vers le client identifié par l'ID 10. Cela se produit parce que la nouvelle clé contient le préfixe utilisateur: qui est le préfixe abonné par le client de suivi activé. Comme vous pouvez le voir, le serveur ne suive aucune des clés que chaque client récupére, mais il diffuse des messages d'invalidation si le préfixe de clé modifié correspond au préfixe abonné par chaque client.

Options Optin et Optout

Les options Optin et Optout peuvent être utilisées pour filtrer les touches que le serveur doit suivre exactement ou non suivre. Avec ces options activées dans la commande de suivi client, Redis ne garde que les clés qui sont des questions juste après la commande de Caching Yes Caching Yes. Cela minimise l'utilisation de la mémoire côté serveur et se charge considérablement.

Conclusion

En résumé, la mise en cache côté client est l'une des techniques largement utilisées pour améliorer les performances des applications Web qui demandent fréquemment des données dans les bases de données arrière. Comme indiqué, le navigateur ou le serveur d'applications côté client peut contenir les données liées aux requêtes populaires émises par le client. Comme mentionné dans l'introduction, dans Redis, la mise en cache côté client est appelée suivi. De plus, les deux modes de suivi sont disponibles en redis. Le client dédié et les modes de diffusion ont leurs propres cas d'utilisation.