Quel est le mécanisme asynchrone de Redis

1. Points de blocage Redis

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 ;

• Nœuds maître-esclave : la bibliothèque maître génère et transmet des fichiers RDB, la bibliothèque esclave reçoit des fichiers RDB, efface la base de données et charge les fichiers RDB ;

• Découpage des instances de cluster : transmettez les informations sur les emplacements de hachage à d'autres instances et migrez les données.

• 4 La relation entre les objets interactifs de classe et les opérations spécifiques :

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ète

opérations HGETALL, SMEMBERS et

statistiques d'agrégation

opé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.

Ce processus lui-même prend un certain temps et bloquera l'application qui libère actuellement de la mémoire. Si une grande quantité de mémoire est libérée en même temps, le temps de fonctionnement de la liste liée des blocs de mémoire libres augmentera, ce qui entraînera en conséquence le problème. Le thread principal Redis doit être bloqué.

Il est temps de libérer une grande quantité de mémoire : lors de la suppression d'un grand nombre de paires clé-valeur, la suppression d'une collection contenant un grand nombre d'éléments est également appelée

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 ;

• Plus les éléments de l'ensemble sont grands, plus la suppression est longue

• Lors de la suppression d'un ensemble contenant 1 million d'éléments, la taille maximale du type de hachage Le temps de suppression ; a atteint une valeur absolue de 1,98 seconde. Dans des circonstances normales, le temps de réponse de Redis est de l'ordre de la microseconde, mais si une opération prend près de 2 secondes à s'exécuter, elle bloquera le thread principal, ce qui est inévitable.

• Le troisième point de blocage de Redis : effacer la base de données
  Étant donné que la suppression fréquente de paires clé-valeur est un point de blocage potentiel, l'effacement de la base de données (comme les opérations FLUSHDB et FLUSHALL) est également un point de blocage potentiel dans la base de données Redis Opérations au niveau. Risque de blocage car cela implique la suppression et la libération de toutes les paires clé-valeur.

Le quatrième point bloquant de Redis : l'écriture synchrone des logs AOF

Les E/S disque prennent généralement beaucoup de temps et de main d'œuvre et nécessitent de la concentration. Les développeurs Redis reconnaissent depuis longtemps que les E/S du disque peuvent provoquer un blocage. Redis est donc conçu pour utiliser un sous-processus pour générer des fichiers d'instantanés RDB et effectuer des opérations de réécriture du journal AOF. Le processus enfant est responsable de l'exécution et les E/S lentes du disque ne bloqueront pas le thread principal.

Si Redis enregistre directement les journaux AOF, il utilisera différentes stratégies d'écriture pour écrire les données sur le disque. Une opération d'écriture synchrone sur disque prend environ 1 à 2 ms. Si un grand nombre d'opérations d'écriture doivent être enregistrées dans le journal AOF et réécrites de manière synchrone, le thread principal sera bloqué.

Le cinquième point bloquant de Redis : le chargement des fichiers RDB depuis la bibliothèque esclave

Dans un cluster maître-esclave, la bibliothèque maître doit générer des fichiers RDB et les transférer vers la bibliothèque esclave.

Pendant le processus de copie de la bibliothèque principale,

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.

Points de blocage lors de l'interaction avec les instances de cluster de découpage

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

Afin d'éviter les opérations de blocage, Redis fournit un mécanisme de thread 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.

Exigences pour l'exécution asynchrone des opérations :

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.

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 2 doit renvoyer le résultat au client. Il s'agit d'une opération sur le chemin critique, le thread principal doit donc terminer cette opération immédiatement.

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.

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.

• "É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.

3. Mécanisme de sous-thread asynchrone

• 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

  AOF, clé -suppression de paires de valeurs et fermeture de fichiers
.

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.

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é.

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.

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!