Guide d'optimisation Redis : réseau, mémoire, disque, points de blocage

Étant donné que Redis est une opération basée sur la mémoire, le processeur ne constitue pas un goulot d'étranglement en termes de performances. Au contraire, l'utilisation de la mémoire du serveur, les E/S réseau et les lectures et écritures sur le disque jouent un rôle clé dans les performances de Redis.

Par conséquent, nous nous concentrerons sur l'optimisation d'aspects tels que le réseau, la mémoire, le disque et les points de blocage. Si une terminologie n'est pas claire, il est recommandé de se référer au contenu redis dans les numéros précédents ou de consulter les informations pertinentes.

Optimisation du réseau

Si le client demande au serveur, c'est-à-dire en mode "requête-réponse", utilisez autant que possible le traitement par lots pour réduire la surcharge d'E/S du réseau.

Technologie de traitement par lots : instructions de traitement par lots atomiques m, technologie pipline, redis, transactions, scripts lua.

Le traitement par lots réduit la surcharge des E/S du réseau

Instructions de traitement par lots Atomic m : type de chaîne, il est recommandé d'utiliser mget/mset au lieu de get/set ; il est recommandé d'utiliser hmget/hmset au lieu de hget/hset.

Technologie Pipeline : la technologie Pipeline peut être utilisée lorsqu'il y a des opérations par lots lors de l'utilisation de list, set et zset.

Transaction Redis : recommandée lorsque des exigences commerciales particulières nécessitent plusieurs instructions.

Script Lua : Il est recommandé d'utiliser le script Lua lorsque vous devez garantir l'atomicité de plusieurs instructions. Des exemples spécifiques incluent le déverrouillage distribué, les ventes flash et la réduction des stocks.

Optimisation du réseau inter-nœuds

Créer un cluster dans le même LAN ;

Contrôlez le nombre de nœuds dans le cluster divisé, les emplacements de hachage alloués sur l'instance Redis doivent être transférés entre différentes instances, et lorsque l'instance d'équilibrage de la dette est supprimée, les données seront transférées entre différentes instances. Mais les informations sur les emplacements de hachage ne sont pas volumineuses et la migration des données est progressive, mais ce n'est pas le problème principal ;

Optimisation de la mémoire

Contrôler la longueur de la clé : Il est recommandé de définir le cahier des charges avant le développement pour s'assurer que la clé est simple et claire, et d'abréger au maximum la clé en fonction du métier.

Évitez les bigkey : la taille recommandée du type de chaîne est inférieure à 20 Ko. Il est recommandé de contrôler le seuil de hachage, list, set et zset, et il est recommandé de le contrôler dans les 5 000.

Le paramètre clé expire : utilisez pleinement la mémoire.

Choisissez la bonne structure de données

Type String, il est recommandé d'utiliser le type entier. Son encodage sous-jacent choisira un encodage entier, qui a une faible surcharge de mémoire ;

Type de hachage, il est recommandé de contrôler le seuil d'élément. Lorsqu'il y a peu d'éléments, la couche inférieure utilisera une structure de données de liste compressée, qui a une faible surcharge de mémoire, il est recommandé de contrôler le seuil d'élément. il y a peu d'éléments, la couche inférieure utilisera une structure de données de liste compressée, qui a une faible surcharge de mémoire, il est recommandé de stocker le type Integer, son codage sous-jacent choisira un codage entier et la surcharge de mémoire est faible ;

Type zset, il est recommandé de contrôler le seuil des éléments. Lorsqu'il y a peu d'éléments, la couche inférieure utilisera une structure de données de liste compressée, qui a une faible surcharge de mémoire ;

Compression des données : le client peut utiliser des algorithmes de compression tels que snappy et gzip pour compresser les données avant d'écrire sur Redis afin de réduire l'utilisation de la mémoire. Cependant, le client doit décompresser les données après avoir lu les données, ce qui consommera plus de CPU.

Activer la stratégie d'élimination de la mémoire

Mettez fin à la stratégie d'élimination de la mémoire par défaut. Veuillez choisir une stratégie d'élimination appropriée en fonction de votre activité réelle pour améliorer l'utilisation de la mémoire.

LRU : concentrez-vous sur le nombre de visites, éliminez les clés les moins récemment utilisées et disposez d'un large éventail de scénarios d'utilisation. Le LRU de Redis utilise un algorithme similaire au LRU, ajoutant un champ supplémentaire d'une longueur de 24 bits à la clé, qui est l'horodatage du dernier accès. Adoptez une méthode de traitement paresseuse : lors de l'exécution d'une opération d'écriture, si la mémoire maximale est dépassée, l'algorithme d'élimination LRU est exécuté une fois, 5 clés (le nombre peut être défini) sont échantillonnées de manière aléatoire et la clé la plus ancienne est éliminée. la mémoire maximale est toujours dépassée après l'élimination, l'élimination continuera.

LFU : Focus sur la fréquence d'accès, recommandé face à la pollution du cache.

Problème d'optimisation de la fragmentation de la mémoire

Raisons : L'une est due à la stratégie d'allocation de l'allocateur de mémoire. L'allocateur de mémoire alloue selon une taille fixe, plutôt qu'en fonction de la taille réelle demandée. Par exemple, si les octets demandés se trouvent dans les octets demandés, 32 octets le sont. effectivement alloué ; l'autre est causé par redis. Une fois la paire clé-valeur supprimée, la fragmentation de la mémoire causée par une partie de l'espace sera libérée.

Positionnement : observez l'indicateur de men_fragmentation_ratio via l'instruction INFO mémoire ; si l'indicateur est compris entre 1 et 1,5, c'est normal ; si l'indicateur est supérieur à 1,5, le taux de fragmentation de la mémoire a dépassé 50 % et la fragmentation de la mémoire doit être traité ;

Solution : redémarrez l'instance Redis ;

Activez la fonction de nettoyage automatique de la fragmentation de la mémoire de Redis.

Optimisation du disque

Construire physiquement le service redis : lors de la persistance, redis utilise la méthode de création d'un processus enfant (qui appellera le système fork du système d'exploitation), et l'environnement de la machine virtuelle met plus de temps à exécuter fork que la machine physique.

Mécanisme d'optimisation de la persistance

Ne pas activer la persistance : redis n'est utilisé que pour la mise en cache, il n'est donc pas nécessaire d'activer la persistance pour réduire la surcharge du disque ;

Optimisation AOF : traitez AOF en arrière-plan, configurez apenfsync eachec pour placer l'opération de pinceau de persistance des données dans le thread d'arrière-plan à exécuter et essayez de réduire l'impact de l'écriture Redis sur le disque sur les performances ;

Ne créez pas de persistance AOF à haute fréquence. La fréquence par défaut de la persistance AOF est d'une fois par seconde. Il n'est pas recommandé de modifier cette configuration. Cela peut déjà garantir que les données seront perdues jusqu'à 1 seconde ;

Activez la persistance hybride, redis4.0 prend en charge la persistance hybride RDB + AOF incrémentiel ;

Activer la configuration multithread. Avant Redis 6.0, la persistance était gérée via le processus enfant fork du thread principal, mais fork était bloqué de manière synchrone. Après la version 6.0, plusieurs processus sont pris en charge pour gérer les opérations de persistance ;

Optimisation du cluster

L'esclave effectue l'optimisation de la persistance : le maître n'effectue pas de persistance et partage autant que possible la pression des E/S du disque maître ; optimisation maître-esclave : mode incrémentiel, la méthode de synchronisation maître-esclave est désignée comme mode incrémentiel et le mode RDB complet ne sera pas sélectionné. Le mode complet One consomme beaucoup de performances ; en utilisant le mode de synchronisation en cascade, lorsqu'un maître a plusieurs esclaves, plusieurs esclaves viennent au maître pour synchroniser les données, ce qui réduira directement les performances du maître.

Pour ce problème, Redis prend en charge la synchronisation en cascade, c'est-à-dire que le maître synchronise uniquement les données sur une seule salve, puis les données des autres salves sont synchronisées à partir de cette salve pour soulager la pression sur le maître.

Il est recommandé que la taille réelle ne dépasse pas 6G. Si l'instance est trop volumineuse, la synchronisation maître-esclave sera bloquée et, dans les cas graves, elle fera tomber le maître.

AOF sera rejoué lors d'un redémarrage anormal. Si l'instance est trop volumineuse, la récupération des données sera anormalement lente.

Optimisation des points d'étranglement

Analyse : étant donné que Redis est monothread lors du traitement des requêtes et des instructions, son goulot d'étranglement en termes de performances est le problème de blocage de la synchronisation.

gros problème

Dangers : la lecture et l'écriture de bigkey peuvent entraîner un délai d'attente, et redis exploite les données dans un seul thread, ce qui peut sérieusement bloquer l'ensemble du service redis. De plus, une clé ne sera divisée qu’en un seul nœud, la pression du dessin ne pourra donc pas être partagée. Détection Bigkey : livré avec la commande bredis-cli-bigkeys. Redis est livré avec des instructions qui ne peuvent trouver que la plus grande clé parmi les cinq types de données, ce qui n'est pas très utile et n'est pas recommandé. script d'analyse python. Il peut localiser des clés spécifiques, mais la précision n’est pas élevée et n’est pas recommandée.

Outil rdb_bigkeys. Outil écrit en Go, il est rapide et très précis. Il peut également être directement exporté vers un fichier csv pour une visualisation et une recommandation faciles.

Optimisation : pour les bigkey de type non-chaîne, l'ensemble d'éléments peut être divisé en multiples. Par exemple, si un bigkey est divisé en 1000 clés, le suffixe de la clé sera haché modulo 1000.

Utilisez le cache local, par exemple, stockez l'ID d'entreprise + le numéro de version dans Redis, placez le contenu spécifique dans le cache local, vérifiez d'abord le cache Redis pour chaque requête, puis vérifiez le numéro de version avec le cache local.

L'optimisation de bigkey est généralement laborieuse. Il est recommandé de définir des spécifications lors du développement pour éviter les problèmes de bigkey.

Politique d'expiration

Suppression programmée : chaque clé expirée reçoit une tâche planifiée et elle est supprimée directement lorsqu'elle expire. Elle a une utilisation élevée de la mémoire et une utilisation élevée du processeur. Suppression paresseuse : lorsque la clé est interrogée, il est déterminé si la clé a expiré. Si elle a expiré, elle sera supprimée. Cela entraînera une faible utilisation du processeur et une utilisation élevée de la mémoire. Suppression périodique : analysez de temps en temps, les clés expirées sont directement supprimées et l'utilisation du processeur et de la mémoire est moyenne.

1. Stratégie gourmande. Redis définira la clé expirée dans un dictionnaire séparé.

2. Processus de numérisation. Sélectionnez 20 clés dans le dictionnaire expiré et supprimez les clés expirées parmi les 20 clés. Si la proportion de clés supprimées dépasse 1/4, répétez l’étape 1.

Sur la base de la logique ci-dessus, afin de résoudre le problème de thread bloqué en raison d'une boucle excessive, un mécanisme de délai d'attente est ajouté à l'algorithme. Le temps par défaut est de 25 ms.

3. Fréquence d'analyse : redis est par défaut de 10 analyses d'expiration par seconde.

Redis active la suppression paresseuse + la suppression régulière par défaut.

Optimisation : activez le mode paresseux et les opérations fastidieuses de libération de mémoire seront exécutées dans le thread d'arrière-plan, pris en charge par redis4.0+.

Activez le mode multi-thread. Avant Redis 6.0, la politique d'expiration était une opération synchrone du thread principal. Après la version 6.0, le multi-threading est utilisé pour le traitement.

Instructions de grande complexité

Il est recommandé d'utiliser le scan pour interroger par lots et de ne pas utiliser de clés. Non applicable aux opérations d'agrégation : redis utilise un modèle monothread pour traiter les requêtes lors de l'exécution de commandes trop complexes (consommant plus de ressources CPU), les requêtes suivantes seront mises en file d'attente et entraîneront des retards, tels que SINTER, SINTERSTORW, ZUNIONSTORE, ZINTERSTORE, etc. Il est recommandé d'utiliser scan pour connaître les éléments de la collection par lots et effectuer des calculs d'agrégation sur le client.

Opération de données de type conteneur : lorsqu'il y a trop d'éléments de type conteneur, la requête directe entraînera des retards dus au réseau. Il est recommandé d'interroger par lots.

Lorsqu'il y a trop d'éléments de conteneur, la suppression directe des clés peut entraîner le gel de Redis. Il est recommandé de les supprimer par lots.

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!