Redis est-il monothread ou multithread ? Pourquoi ?

Avant Redis 4.0, il fonctionnait dans un seul thread ; après Redis 4.0, il a commencé à prendre en charge le multithread. Les raisons pour lesquelles le monothreading était utilisé avant Redis 4.0 : 1. Le mode monothread est pratique pour le développement et le débogage ; 2. Redis utilise le multiplexage basé sur epoll en interne 3. Le principal goulot d'étranglement des performances de Redis est la mémoire ou la bande passante du réseau.

(Partage vidéo d'apprentissage : Tutoriel vidéo Redis)

Différentes versions de Redis sont différentes, dans Redis4 Before. 0, Redis s'exécutait dans un seul thread, mais un seul thread ne signifie pas une faible efficacité. Nginx et Nodejs sont également des programmes monothread, mais leur efficacité n'est pas faible.

La raison est que Redis est basé sur la mémoire. Son goulot d'étranglement réside dans la mémoire de la machine et la bande passante du réseau, et non dans le processeur. Avant que le processeur n'atteigne le goulot d'étranglement, la mémoire de la machine peut être pleine ou la bande passante peut atteindre. le goulot d'étranglement. Par conséquent, le processeur n'est pas la raison principale, donc le monothreading est naturellement utilisé. De plus, l'utilisation du multithreading est plus gênante.

Mais dans Redis 4.0, il a commencé à prendre en charge le multithreading, comme la suppression d'arrière-plan et d'autres fonctions.

Pour faire simple, Redis utilisait le mode mono-thread avant la version 4.0 pour les trois raisons suivantes :

• Utilisation du mode mono-thread de Redis, son développement et sa maintenance sont plus simples, car le mode monothread facilite le développement et le débogage.

• Même en utilisant un modèle monothread, plusieurs requêtes client peuvent être traitées simultanément, principalement parce que Redis utilise le multiplexage basé sur epoll en interne.

• Pour Redis, le principal goulot d'étranglement en termes de performances est la mémoire ou la bande passante réseau, et non le processeur.

Mais Redis a introduit la suppression paresseuse (également appelée suppression asynchrone) dans les versions 4.0 et ultérieures, ce qui signifie que nous pouvons utiliser une méthode asynchrone pour supprimer des données dans Redis, par exemple :

• dissocier la clé : similaire à la clé del, supprimez la clé spécifiée. Si la clé n'existe pas, la clé sera ignorée. Cependant, del provoquera un blocage et la commande unlink récupérera de la mémoire dans un autre thread, c'est-à-dire qu'elle est non bloquante [http://www.redis.cn/commands/unlink.html]

;

• flushdb async : supprimer toutes les données de la base de données actuelle [http://www.redis.cn/commands/flushdb.html] ;

• flushall async : supprimer toutes les données de la bibliothèque Data [http://www.redis.cn/commands/flushall.html].

L'avantage de ce traitement est qu'il ne bloquera pas le thread principal de Redis et que ces opérations seront transmises au thread d'arrière-plan pour exécution.

[L'utilisation de la commande del peut généralement supprimer des données rapidement, mais lorsque la clé supprimée est un objet très volumineux, par exemple : lors de la suppression d'un jeu de hachage contenant des milliers d'éléments, alors l'instruction del provoquera le main Redis thread à geler, donc l'utilisation de la suppression paresseuse peut efficacement éviter le problème de gel de Redis. 】

Analyse des points de test :

Les questions sur le modèle de thread Redis (monothread ou multithread) sont presque l'une des questions que Redis doit se poser, mais ceux qui répondent bien Pas beaucoup. La plupart d'entre eux peuvent seulement répondre que Redis est monothread et énoncer les nombreux avantages du monothreading. Cependant, ils peuvent répondre avec précision aux caractéristiques du multithreading dans Redis4.0 et Redis6.0, surtout dans Redis6.0, il y a très peu de monde. Concernant les connaissances pertinentes du monothreading et du multi-threading, il y a également les questions d'entretien suivantes.

1. Puisque le thread principal de Redis est monothread, pourquoi est-il si rapide ?

2. Introduire le multiplexage IO dans Redis ?

3. Introduire le multithreading dans Redis6.0 ?

1. Pourquoi Redis est-il si rapide ?

Les raisons sont les suivantes :

a. Opérations basées sur la mémoire : toutes les données dans Redis sont stockées en mémoire, donc toutes les opérations sont au niveau de la mémoire, donc ses performances sont relativement élevées. haut.

b.Structure de données simple : La structure de données de Redis est relativement simple et est spécialement conçue pour Redis. La complexité temporelle de la recherche et du fonctionnement de ces structures de données simples est O(1).

c. Multiplexage et IO non bloquants : Redis utilise la fonction de multiplexage IO pour écouter les clients avec plusieurs connexions socket, de sorte qu'un thread puisse être utilisé pour gérer plusieurs situations, réduisant ainsi la surcharge causée par la commutation. évite les opérations de blocage d'E/S, améliorant ainsi considérablement les performances de Redis.

d. Éviter le changement de contexte : comme il s'agit d'un modèle monothread, les changements de contexte inutiles et la concurrence multithread sont évités, ce qui permet d'économiser du temps et des performances causés par le changement multithread. ne cause pas de problèmes de blocage.

Les résultats des tests de référence officiels montrent que Redis monothread peut atteindre un débit de 10 W/S.

2. Qu'est-ce que le multiplexage IO ?

Les méthodes de lecture et d'écriture du socket sont bloquantes par défaut. Par exemple, lorsque la méthode de lecture de l'opération de lecture est appelée, le tampon n'a aucune donnée, alors le thread sera bloqué ici jusqu'à ce que il y a des données dans le tampon. Ou lorsque la connexion est fermée, la méthode de lecture reviendra et le thread pourra continuer à traiter d'autres affaires.

Mais cela réduit évidemment l'efficacité d'exécution du programme, et Redis utilise des IO non bloquantes, ce qui signifie que le processus de lecture et d'écriture des IO ne bloque plus et que les méthodes de lecture et d'écriture sont terminées et renvoyées instantanément. pour dire, il utilisera la stratégie consistant à lire autant qu'il peut lire et à écrire autant qu'il peut écrire pour effectuer des opérations d'E/S, ce qui est évidemment plus conforme à notre recherche de performances.

Mais ce type d'E/S non bloquantes est également confronté à un problème, c'est-à-dire que lorsque nous effectuons une opération de lecture, il est possible que seule une partie des données soit lue ; il en va de même pour l'écriture de données, lorsque le tampon est plein et que nos données n'ont pas encore été écrites, la question se pose alors de savoir quand les données effectives seront écrites.

Le multiplexage des IO résout le problème ci-dessus. La façon la plus simple d'utiliser le multiplexage des IO est d'utiliser la fonction select. Cette fonction est l'interface API fournie par le système d'exploitation au programme utilisateur. surveiller la lisibilité et l'écriture de plusieurs descripteurs de fichiers, de sorte que les événements de lecture et d'écriture des descripteurs de fichiers puissent être surveillés. Lorsque l'heure correspondante est surveillée, le thread peut être informé du traitement de l'activité correspondante, garantissant ainsi l'exécution normale de la fonction de lecture et d'écriture Redis.

[Cependant, la fonction select n'est fondamentalement pas applicable au système d'exploitation actuel, et la fonction epoll (Linux) est appelée à la place. macOS utilise Kqueue (hérité d'Unix), car la fonction select est très importante dans le descripteur de fichier les performances sont très médiocres lorsqu'il y en a plusieurs. 】

3. Multi-threading dans Redis6.0 ?

L'avantage du monothread de Redis est très grand. Il réduit non seulement la responsabilité de la mise en œuvre interne de Redis, mais permet également d'effectuer toutes les opérations sans verrous, et il n'y a pas de blocage ou d'impasse. changement de thread. performances et consommation de temps ; mais ses défauts sont également évidents. Le mécanisme à thread unique rend difficile l'amélioration efficace du QPS (Query Per Second, requêtes par seconde) (bien qu'il soit assez rapide, les gens doivent quand même avoir des performances plus élevées). poursuite).

Bien que Redis ait introduit le multi-threading dans la version 4.0, cette version du multi-threading ne peut être utilisée que pour la suppression asynchrone de grandes quantités de données et n'a pas une grande importance pour les opérations de non-suppression.

Si nous utilisons le multithreading Redis, nous pouvons partager la pression des E/S de lecture et d'écriture synchrones de Redis, utiliser pleinement les ressources CPU multicœurs et améliorer efficacement le QPS de Redis. Bien que Redis utilise le multiplexage des E/S et fonctionne sur la base d'E/S non bloquantes, la lecture et l'écriture des E/S elles-mêmes sont bloquantes. Par exemple, lorsqu'il y a des données dans le socket, Redis copiera d'abord les données de l'espace noyau vers l'espace utilisateur, puis effectuera les opérations associées. Cependant, ce processus de copie est bloquant, et lorsque la quantité de données est plus importante, le processus de copie est bloqué. le temps requis pour la copie augmentera, et ces opérations seront effectuées sur la base d'un seul thread.

Par conséquent, la fonction multi-threading a été ajoutée dans Redis6.0 pour améliorer les performances de lecture et d'écriture des IO. Son idée principale d'implémentation est de diviser les tâches de lecture et d'écriture des IO du thread principal en un groupe de. threads indépendants. Exécution, de sorte que la lecture et l'écriture de plusieurs sockets puissent être parallélisées, mais les commandes Redis sont toujours exécutées en série par le thread principal.

Mais remarque : Redis 6.0 désactive le multithreading par défaut, mais il peut être activé en définissant io-threads-do-reads dans le fichier de configuration redis.conf égal à true. Mais cela ne suffit pas. De plus, nous devons également définir le nombre de threads pour activer correctement la fonction multi-thread. Nous devons également modifier la configuration de Redis, comme définir io-threads 4, ce qui signifie ouvrir 4 threads.

[Concernant le réglage du nombre de threads, la recommandation officielle est que s'il s'agit d'un processeur à 4 cœurs, alors définissez le nombre de threads à 2 ou 3 s'il s'agit d'un processeur à 8 cœurs, puis définissez le nombre de threads sur 6. Bref, le nombre de threads est certain. Il doit être inférieur au nombre de cœurs CPU de la machine. Plus le nombre de threads est grand, mieux c'est. 】

Concernant les performances de Redis, l'auteur de Redis a mentionné lors de la conférence RedisConf 2019 que la fonctionnalité IO multithread introduite dans Redis 6.0 a au moins doublé les performances. Les Chinois ont également effectué des tests comparatifs en utilisant la version Redis à 4 threads et la version Redis à thread unique sur Alibaba Cloud. Ils ont constaté que les résultats des tests étaient cohérents avec ce que l'auteur de Redis avait dit et que les performances pouvaient être pratiquement doublées.

Résumé :

Cet article présente les raisons pour lesquelles Redis est toujours rapide en monothread avant la version 4.0 : basé sur le fonctionnement de la mémoire, la structure de données simple, le multiplexage des E/S et les E/S non bloquantes, évitant les Threads inutiles changement de contexte. Et dans Redis 4.0, il a commencé à prendre en charge le multithreading, ce qui se reflète principalement dans la suppression asynchrone du Big Data, tels que : clé de dissociation, flushdb async, flushall async, etc. Le multithreading de Redis 6.0 augmente la capacité de concurrence de lecture et d'écriture des E/S, qui est utilisée pour mieux améliorer les performances de Redis.

Pour plus de connaissances liées à la programmation, veuillez visiter : Enseignement de la programmation ! !

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!