Objets qui interagissent avec les instances Redis et opérations qui se produisent pendant l'interaction :
Client : IO réseau, ajout de paires clé-valeur, opérations de suppression, de modification et de requête, opérations de base de données ;
disque : génère des instantanés RDB, enregistre les journaux AOF et réécrit les journaux AOF ;Points de blocage lors de l'interaction avec les clients :
Les IO réseau sont parfois lentes, mais Redis utilise les IO multicanaux Le mécanisme de réutilisation empêche le principal le thread n'attend pas toujours l'arrivée des connexions réseau ou des requêtes, donc les E/S réseau ne sont pas un facteur qui provoque le blocage de Redis.
La tâche principale du thread principal Redis est d'effectuer les opérations d'ajout, de suppression, de modification et d'interrogation des paires clé-valeur qui interagissent avec le client. Les opérations d'ajout, de suppression, de modification et de requête très complexes bloqueront définitivement Redis.La norme pour juger de la complexité d'une opération : voyez si la complexité de l'opération est O(N)
. Le premier point bloquant de Redis : requête de collection complète et opération d'agrégation :La complexité des opérations impliquant des collections dans Redis est généralement O(N), vous devez donc y faire attention lorsque vous l'utilisez. Par exemple, les éléments d'ensemble
requête complèteopérations HGETALL, SMEMBERS et
statistiques d'agrégationopérations d'ensembles, telles que l'intersection, l'union et la différence.
Le deuxième point bloquant de Redis : l'opération de suppression de bigkeyL'opération de suppression de la collection elle-même présente également des risques de blocage potentiels. L'essence de l'opération de suppression est de libérer l'espace mémoire occupé par la paire clé-valeur. La libération de mémoire n'est que la première étape. Afin de gérer plus efficacement l'espace mémoire, lorsqu'une application libère de la mémoire, le système d'exploitation doit insérer le bloc de mémoire libéré dans une liste chaînée de blocs de mémoire libres pour une gestion et une réallocation ultérieures.
suppression de grande clé
. Le temps consommé lors de la suppression d'ensembles avec un nombre différent d'éléments :
Trois conclusions sont tirées :
Lorsque le nombre d'éléments passe de 100 000 à 1 million, suppression de 4 grands types de collections L'augmentation du temps est passé de 5 fois à près de 20 fois ;la création et le transfert des fichiers RDB sont effectués par des processus enfants
et ne bloqueront pas le thread principal.Mais après avoir reçu le fichier RDB, la bibliothèque esclave doit utiliser la commande FLUSHDB pour effacer la base de données actuelle, ce qui atteint le troisième point de blocage.
Après avoir effacé la base de données actuelle, la bibliothèque esclave doit charger le fichier RDB dans la mémoire. La vitesse de ce processus est étroitement liée à la taille du fichier RDB. Plus le fichier RDB est volumineux, plus le processus de chargement est lent. Lors du déploiement d'un cluster de découpage Redis, les informations d'emplacement de hachage allouées sur chaque instance Redis doivent être transférées entre différentes instances lorsque équilibrage de charge est requis ou des instances sont ajoutées ou supprimées. , les données seront migrées entre différentes instances. Cependant, la quantité d'informations dans le slot de hachage n'est pas importante et la migration des données est effectuée de manière incrémentielle. Ces deux types d'opérations présentent peu de risques de bloquer le thread principal Redis. Si la solution Redis Cluster est utilisée et que bigkey est migré en même temps, le thread principal sera bloqué car Redis Cluster utilise la migration synchrone. Cinq points de blocage : définir les opérations complètes de requête et d'agrégation ; écriture de synchronisation du journal AOF ; Charger depuis la bibliothèque Fichier RDB. 2. Points de blocage pouvant être exécutés de manière asynchrone Redis démarrera certains sous-threads, puis confiera certaines tâches à ces sous-threads et laissez-les s'exécuter en arrière-plan. Terminé sans que le thread principal n'effectue ces tâches. Cela évite de bloquer le thread principal. Lorsque le thread enfant effectue l'opération 1, le client envoie l'opération 2 à l'instance Redis. Le client doit utiliser le résultat des données renvoyé par l'opération 2. Si l'opération 2 ne renvoie pas de résultat, le client sera toujours dans un état d'attente. . L'opération 1 n'est pas considérée comme une opération sur le chemin critique, car elle n'a pas besoin de renvoyer de données spécifiques au client, elle peut donc être exécutée de manière asynchrone par le sous-thread d'arrière-plan. L'opération de lecture Redis est une opération de chemin critique typique, car une fois que le client a envoyé l'opération de lecture, il attendra que les données lues soient renvoyées pour un traitement ultérieur des données. Le premier point bloquant de Redis, « la requête complète de collecte et l'opération d'agrégation », impliquent tous deux des opérations de lecture et les opérations asynchrones ne peuvent pas être effectuées. "Écriture synchrone du journal AOF", afin de garantir la fiabilité des données, l'instance Redis doit s'assurer que les enregistrements d'opération dans le journal AOF ont été placés sur le disque. Bien que cette opération nécessite que l'instance attende, elle ne le fera pas. renvoyer des résultats de données spécifiques à l'instance. Par conséquent, un thread enfant peut être démarré pour effectuer une écriture synchrone du journal AOF. Afin de fournir des services d'accès aux données aux clients, le fichier RDB complet doit être chargé. Cette opération est également une opération sur le chemin critique et doit être exécutée par le thread principal de la bibliothèque esclave. À l'exception des « opérations de requête complète et d'agrégation de collection » et du « chargement de fichiers RDB à partir de la bibliothèque », les opérations impliquées dans les trois autres points de blocage ne sont pas sur le chemin critique. Vous pouvez utiliser le mécanisme de sous-thread asynchrone de Redis pour. réaliser la suppression et l'effacement des grandes clés. La base de données et le journal AOF sont écrits de manière synchrone. Une fois le thread principal Redis démarré, il utilisera la fonction pthread_create fournie par le système d'exploitation pour créer 3 sous-threads, responsables de l'exécution asynchrone des opérations d'écriture de journal Le thread principal interagit avec les threads enfants via une file d'attente de tâches sous la forme d'une liste chaînée. Mais en fait, la suppression n'a pas été exécutée pour le moment. Une fois que le sous-thread d'arrière-plan a lu la tâche dans la file d'attente des tâches, il commence à supprimer les paires clé-valeur et à libérer l'espace mémoire correspondant. Cette suppression asynchrone est également appelée suppression paresseuse (lazy free). Lorsque le journal AOF est configuré avec l'option Everysec, le thread principal encapsulera l'opération d'écriture du journal AOF dans une tâche et la placera dans la file d'attente des tâches. Une façon de le réécrire est :
Lorsque le sous-thread d'arrière-plan lit la tâche, il commence automatiquement à enregistrer dans le journal AOF et le thread principal peut continuer à s'exécuter sans s'appuyer sur le journal AOF. Mécanisme d'exécution de sous-thread asynchrone dans Redis :
Les opérations de suppression asynchrone de paires clé-valeur et d'effacement de base de données sont des fonctions fournies après Redis 4.0. Redis fournit également de nouvelles commandes pour effectuer ces deux opérations : Suppression de paires clé-valeur : il existe un grand nombre d'éléments dans le type de collection. (comme lorsqu'il y a des millions ou des dizaines de millions d'éléments) qui doivent être supprimés, il est recommandé d'utiliser la commande UNLINK Effacer la base de données : vous pouvez ajouter l'option ASYNC après les commandes FLUSHDB et FLUSHALL ; laissez le sous-thread d’arrière-plan effacer la base de données de manière asynchrone. Points de blocage lors de l'interaction avec les instances de cluster de découpage
Une opération qui peut être exécutée de manière asynchrone n'est pas une opération sur le chemin critique du thread principal Redis (le client envoie la requête à Redis et attend que Redis renvoie le résultat des données).
Une fois que le thread principal a reçu l'opération 1, l'opération 1 n'a pas besoin de renvoyer des données spécifiques au client. Le thread principal peut les transmettre au sous-thread d'arrière-plan pour la terminer, et en même temps, elle uniquement. doit renvoyer un résultat "OK" au client.
Les opérations de suppression qui ne nécessitent pas que des résultats de données spécifiques soient renvoyés au client ne sont pas des opérations de chemin critique. "La" suppression de grandes clés "et" l'effacement de la base de données "impliquent toutes deux la suppression de données, mais elles ne se trouvent pas sur le chemin critique.". Vous pouvez utiliser des sous-threads d'arrière-plan pour effectuer des opérations de suppression de manière asynchrone.
Lors de la réception de l'opération de suppression de la paire clé-valeur et d'effacement de la base de données, le thread principal encapsulera l'opération dans une tâche, la placera dans la file d'attente des tâches, puis renverra un message d'achèvement au client, indiquant que la suppression a été complété.
FLUSHDB ASYNC
FLUSHALL AYSNC
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!