Comment distribuer Redis

1 Pourquoi utiliser Redis

Lors de l'utilisation de Redis dans un projet, il y a deux considérations principales : les performances et la concurrence. S'il s'agit uniquement d'autres fonctions telles que les verrous distribués, il existe à la place d'autres middlewares tels que Zookpeer, et il n'est pas nécessaire d'utiliser Redis.

Performance :

Comme le montre la figure ci-dessous, il est particulièrement adapté lorsque l'on rencontre du SQL qui prend un temps particulièrement long à s'exécuter et que les résultats font ne change pas fréquemment. Mettez les résultats en cours d'exécution dans le cache . De cette manière, les requêtes ultérieures seront lues à partir du cache, afin de pouvoir répondre rapidement aux requêtes.

Surtout dans le système de vente flash, en même temps, presque tout le monde clique et passe des commandes. . . La même opération est effectuée : interroger la base de données pour obtenir des données.

En fonction de l'effet d'interaction, il n'y a pas de norme fixe pour le temps de réponse. Dans un monde idéal, nos sauts de page doivent être résolus en un instant, et les opérations sur la page doivent être résolues en un instant.

Concurrence :

Comme le montre la figure ci-dessous, en cas de concurrence importante, toutes les requêtes accèdent directement à la base de données et une exception de connexion se produira dans la base de données . À ce stade, vous devez utiliser Redis pour effectuer une opération de mise en mémoire tampon afin que la requête puisse d'abord accéder à Redis au lieu d'accéder directement à la base de données.

Questions fréquemment posées sur l'utilisation de Redis

• Problèmes de cohérence en double écriture du cache et de la base de données
• Problème d'avalanche de cache
• Problème de panne de cache
• Problème de concurrence de concurrence de cache

2 Pourquoi Redis à thread unique est-il si rapide

Cette question est une enquête sur le mécanisme interne de Redis. Beaucoup de gens ne savent pas que Redis dispose d'un modèle de travail à thread unique.

Les principales raisons sont les trois points suivants :

• Fonctionnement en mémoire pure
• Fonctionnement monothread, évitant les changements de contexte fréquents
• Adopte un mécanisme de multiplexage d'E/S non bloquant

Parlons en détail du mécanisme de multiplexage d'E/S. Utilisons une analogie : Xiao Ming a ouvert un restaurant de restauration rapide dans la ville A. . DianDian est responsable du service de restauration rapide de la ville. En raison de contraintes financières, Xiao Ming a embauché un groupe de livreurs. Ensuite, Xiao Qu a constaté que les fonds n'étaient pas suffisants et qu'il ne pouvait acheter qu'une voiture pour livrer une livraison express.

Méthode commerciale 1

Chaque fois qu'un client passe une commande, Xiao Ming demandera à un livreur de la surveiller, puis de demander à quelqu'un de la livrer. Lentement, Xiaoqu a découvert les problèmes suivants avec cette méthode commerciale :

Tout le temps était passé à récupérer les voitures, et la plupart des livreurs étaient inactifs. Une voiture peut être utilisée pour les livrer.

• À mesure que le nombre de commandes augmentait, il y avait également de plus en plus de livreurs. Xiao Ming a constaté que le magasin express devenait de plus en plus encombré et qu'il n'y avait aucun moyen d'embaucher de nouveaux livreurs.
• La coordination entre les livreurs prend du temps.
• Sur la base des lacunes ci-dessus, Xiao Ming a tiré les leçons de l'expérience et a proposé la deuxième méthode commerciale.

Mode Business 2

Xiao Ming n'embauche qu'un seul livreur. Lorsqu'un client passe une commande, Xiao Ming marque le lieu de livraison et le place au même endroit. Enfin, laissez le livreur conduire la voiture pour livrer les articles un par un, et revenez chercher le suivant après la livraison. En comparant les deux méthodes commerciales ci-dessus, il est évident que la seconde est plus efficace.

Dans la métaphore ci-dessus :

• Chaque livreur→Chaque fil
• Chaque commande→Chaque socket (flux E/S)
• Le lieu de livraison de la commande→ Statut différent de Socket
• Demande de livraison de nourriture du client→Demande du client
• Méthode commerciale de Mingqu→Le code exécuté par le serveur
• Le nombre de cœurs d'une voiture→CPU

Nous avons donc la conclusion suivante :

• La première méthode commerciale est le modèle de concurrence traditionnel, chaque flux d'E/S (ordre) est géré par un nouveau thread (livreur).
• La deuxième méthode de gestion est le multiplexage des E/S. Il n'existe qu'un seul thread (un livreur) qui gère plusieurs flux d'E/S en suivant l'état de chaque flux d'E/S (l'emplacement de livraison de chaque livreur).

Ce qui suit est une analogie avec le véritable modèle de thread Redis, comme le montre la figure :

Le client Redis aura des caractéristiques différentes lorsque fonctionnement Socket de type événement. Côté serveur, il existe un multiplexeur d'E/S qui le met dans une file d'attente. Ensuite, le répartiteur d'événements de fichier le extrait tour à tour de la file d'attente et le transmet à différents processeurs d'événements.

Trois types de données Redis et scénarios d'utilisation

Un programmeur qualifié utilisera ces cinq types.

String

L'opération set/get la plus courante, Value peut être une chaîne ou un nombre. Généralement, une certaine mise en cache de fonctions de comptage complexes est effectuée .

Hash

Ici, Value stocke un objet structuré, et il est plus pratique d'y exploiter un certain champ. Lorsque je faisais une authentification unique, j'utilisais cette structure de données pour stocker les informations utilisateur, en utilisant CookieId comme clé et en définissant 30 minutes comme délai d'expiration du cache, ce qui peut très bien simuler un effet de type session.

Liste

En utilisant la structure de données List, vous pouvez exécuter des fonctions simples de file d'attente de messages. De plus, vous pouvez utiliser la commande lrange pour implémenter la fonction de pagination basée sur Redis , qui offre d'excellentes performances et une bonne expérience utilisateur.

Set

Parce que Set est une collection de valeurs uniques. Par conséquent, la fonction de déduplication globale peut être implémentée. Nos systèmes sont généralement déployés en clusters, et il est gênant d'utiliser le Set fourni avec la JVM. De plus, en utilisant l'intersection, l'union, la différence et d'autres opérations, vous pouvez calculer les préférences communes, toutes les préférences, vos propres préférences uniques et d'autres fonctions.

Ensemble trié

L'ensemble trié a un paramètre de poids Score supplémentaire, et les éléments de l'ensemble peuvent être organisés en fonction du score. Vous pouvez utiliser l'application de classement pour obtenir les opérations TOP N. L'ensemble trié peut être utilisé pour effectuer des tâches retardées.

Quatre stratégies d'expiration Redis et mécanisme d'élimination de la mémoire

Cela permet de savoir si Redis est utilisé à la maison. Par exemple, votre Redis ne peut stocker que des données 5G, mais si vous écrivez 10G, 5G de données seront supprimées. Comment l'avez-vous supprimé ? Avez-vous réfléchi à ce problème ?

Bonne réponse : Redis adopte une stratégie de suppression régulière + suppression paresseuse.

Pourquoi ne pas utiliser la stratégie de suppression programmée

Suppression programmée, utiliser une minuterie pour surveiller la clé et la supprimer automatiquement lorsqu'elle expire ? . Bien que la mémoire soit libérée avec le temps, elle consomme beaucoup de ressources CPU. Dans le cas de requêtes simultanées volumineuses, le processeur doit utiliser du temps pour traiter la requête au lieu de supprimer la clé, cette stratégie n'est donc pas adoptée.

Fonctionnement de la suppression régulière + suppression paresseuse

Suppression régulière, Redis vérifie toutes les 100 ms par défaut et supprime les clés expirées. Il convient de noter que Redis ne vérifie pas toutes les clés toutes les 100 ms, mais les sélectionne au hasard pour les vérifier. Si vous adoptez uniquement une stratégie de suppression régulière, de nombreuses clés ne seront pas supprimées à ce moment-là. La suppression paresseuse est donc utile.

N'y a-t-il pas d'autre problème si vous adoptez la suppression régulière + la suppression paresseuse

Non, si la suppression régulière ne supprime pas la Clé ? Et vous n'avez pas demandé la clé à temps, ce qui signifie que la suppression différée n'a pas pris effet. De cette façon, la mémoire de Redis deviendra de plus en plus élevée. Ensuite, le mécanisme d'élimination de la mémoire doit être adopté.

Il y a une ligne de configuration dans redis.conf :

# maxmemory-policy volatile-lru

Cette configuration est équipée de la stratégie d'élimination de mémoire :

• noeviction : lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, la nouvelle opération d'écriture signalera une erreur.
• allkeys-lru : Lorsque la mémoire est insuffisante pour accueillir les données nouvellement écrites, dans l'espace clé, supprimez la clé la moins récemment utilisée. (Recommandé, ceci est actuellement utilisé dans le projet) (L'algorithme le plus récemment utilisé)
• allkeys-random : lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, une clé est supprimée de manière aléatoire de l'espace clé. (Personne ne devrait l'utiliser. Si vous ne la supprimez pas, utilisez au moins la clé et supprimez-la de manière aléatoire)
• volatile-lru : Lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, dans le espace clé avec le délai d'expiration défini, supprimez la clé la moins récemment utilisée. Cette situation est généralement utilisée lorsque Redis est utilisé à la fois comme cache et comme stockage persistant. (Non recommandé)
• volatile-aléatoire : lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, supprimez de manière aléatoire une clé dans l'espace clé avec un délai d'expiration défini. (Toujours déconseillé)
• volatile-ttl : lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, dans l'espace clé avec un délai d'expiration défini, la clé avec un délai d'expiration antérieur sera supprimée en premier. (Non recommandé)

Cinq problèmes de cohérence de Redis et de double écriture de base de données

Les problèmes de cohérence peuvent être divisés en cohérence éventuelle et cohérence forte . Si la base de données et le cache sont écrits en double, il y aura inévitablement des incohérences. Le principe est que s’il existe des exigences strictes de cohérence pour les données, celles-ci ne peuvent pas être mises en cache. Tout ce que nous faisons ne peut que garantir une cohérence à terme.

De plus, la solution que nous avons apportée ne peut fondamentalement que réduire la probabilité d'incohérence. Par conséquent, les données ayant de fortes exigences de cohérence ne peuvent pas être mises en cache. Tout d'abord, adoptez une stratégie de mise à jour correcte, mettez d'abord à jour la base de données, puis supprimez le cache . Deuxièmement, parce que il peut y avoir un problème d'échec de suppression du cache, il suffit de prévoir une mesure de compensation, comme l'utilisation de la file d'attente des messages.

6 Comment gérer les problèmes de pénétration du cache et d'avalanche de cache

Ces deux problèmes sont généralement difficiles à rencontrer pour les petites et moyennes entreprises de logiciels traditionnelles. Si vous avez un grand projet simultané avec un trafic de plusieurs millions de dollars, ces deux problèmes doivent être examinés en profondeur. La pénétration du cache signifie que les pirates demandent délibérément des données qui n'existent pas dans le cache, ce qui entraîne l'envoi de toutes les demandes à la base de données, ce qui rend la connexion à la base de données anormale.

Solution de pénétration du cache :

• Utilisez le verrouillage mutex Lorsque le cache échoue, obtenez d'abord le verrou et obtenez le verrou, et puis demandez la base de données. Si le verrou n'est pas obtenu, il se met en veille pendant un moment et réessaye.
• En utilisant la stratégie de mise à jour asynchrone, il renvoie directement, que la clé ait ou non une valeur. Un délai d'expiration du cache est conservé dans la valeur Valeur. Si le cache expire, un thread sera démarré de manière asynchrone pour lire la base de données et mettre à jour le cache. Une opération de préchauffage du cache (chargement du cache avant de démarrer le projet) est requise.
• Fournissez un mécanisme d'interception capable de déterminer rapidement si la demande est valide, par exemple en utilisant des filtres Bloom pour maintenir en interne une série de clés légales et valides. Déterminez rapidement si la clé transportée dans la demande est légale et valide. Si c'est illégal, revenez directement.

Avalanche de cache, c'est-à-dire que le cache échoue dans une grande zone en même temps. À ce moment-là, une autre vague de requêtes arrive, et par conséquent, les requêtes. sont tous envoyés à la base de données, entraînant une connexion anormale à la base de données.

Solution d'avalanche de cache :

• Ajoutez une valeur aléatoire au délai d'expiration du cache pour éviter un échec collectif.
• utilise le verrouillage mutex, mais le débit de cette solution diminue considérablement.
• Double cache. Nous avons deux caches, le cache A et le cache B. Le délai d'expiration du cache A est de 20 minutes et il n'y a pas de délai d'expiration pour le cache B. Effectuez vous-même l’opération de préchauffage du cache.
• Décomposez ensuite les points suivants : lire la base de données depuis le cache A, et revenir directement s'il y en a ; A n'a pas de données, lire les données directement depuis B, revenir directement et démarrer un thread de mise à jour de manière asynchrone, et le thread de mise à jour met à jour en même temps le cache A et le cache B.

8 Comment résoudre le problème de clé concurrente concurrente de Redis

Ce problème est en gros, Plusieurs sous-systèmes définissent une clé en même temps. À quoi devons-nous faire attention à ce moment-là ? Tout le monde recommande essentiellement d'utiliser le mécanisme de transaction Redis.

Cependant, il n'est pas recommandé d'utiliser le mécanisme de transaction Redis. Étant donné que notre environnement de production est essentiellement un environnement de cluster Redis, des opérations de partitionnement de données sont effectuées. Lorsqu'une transaction implique plusieurs opérations de clé, ces multiples clés ne sont pas nécessairement stockées sur le même serveur Redis. Par conséquent, le mécanisme de transaction de Redis est très inutile.

Si vous opérez sur cette Clé, ne nécessite pas de commande

Dans ce cas, préparez un distribution Tapez lock , tout le monde va saisir le verrou, et effectuez simplement l'opération définie lorsque vous saisissez le verrou, ce qui est relativement simple.

Si vous opérez sur cette clé, nécessite la commande

En supposant qu'il existe une clé1, le système A doit définissez key1 sur valueA, le système B doit définir key1 sur valueB et le système C doit définir key1 sur valueC.

Attendez-vous à ce que la valeur de key1 change dans l'ordre valeurA > valeurB > À ce moment-là, lorsque nous écrivons des données dans la base de données, nous devons enregistrer un horodatage .

Supposons que l'horodatage soit le suivant  :

Clé système A 1 {valeurA 3:00}

Clé système B 1 { valueB 3:05>

Clé du système C 1 {valueC 3:10>

Ensuite, en supposant que le système B saisit le verrou en premier, réglez key1 sur { valeurB 3 :05}. Ensuite, le système A saisit le verrou et constate que l'horodatage de sa propre valeur A est antérieur à l'horodatage dans le cache, il n'effectue donc pas l'opération définie, et ainsi de suite. D'autres méthodes, telles que utiliser des files d'attente et transformer la méthode définie en accès série, peuvent également être utilisées.

Pour plus d'articles techniques liés à Redis, veuillez visiter la colonne Tutoriel Redis pour apprendre !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!