Pourquoi Redis introduit-il le multithreading ?

1. Aperçu du problème

Les versions après Redis 6.0 ont abandonné la conception du modèle monothread, qui utilisait à l'origine une opération monothread, a également commencé à utiliser sélectivement le modèle multithread. il semble que l'auteur de Redis soit tellement génial qu'il n'y a pas d'échappatoire. "La loi du vrai parfum",

Si vous y réfléchissez bien, ce problème peut en fait être divisé en deux questions principales :

(1 ) Pourquoi Redis a-t-il choisi un modèle mono-thread au début (les avantages du mono-threading) ?

(2) Pourquoi Redis a-t-il ajouté le multi-threading après la version 6.0 (dans certains cas, le mono-threading présente des défauts qui peuvent être résolus par le multi-threading) ?

En fait, ce n'est pas que l'auteur n'a pas échappé au vrai théorème du parfum, mais au fil du temps, de plus en plus de problèmes surviennent. La conception originale est définitivement obsolète et des modifications devraient être apportées. OK, avec deux questions, analysons-les attentivement.

2.Pourquoi Redis a-t-il utilisé un seul thread au début ? Qu'il s'agisse d'un seul thread ou de plusieurs threads, c'est pour améliorer l'efficacité du développement de Redis, car Redis est une base de données basée sur la mémoire et gère également un grand nombre de données externes. requêtes réseau. Il est inévitable d’effectuer plusieurs IO. Heureusement, Redis utilise de nombreux excellents mécanismes pour garantir sa haute efficacité. Alors pourquoi Redis est-il conçu en mode monothread ? Cela peut être résumé comme suit :

(1) Multiplexage IO

Jetons un coup d'œil à la conception de haut niveau de Redis.

FD est un descripteur de fichier, ce qui signifie si le fichier actuel est lisible, inscriptible ou anormal. Utilisez le mécanisme de multiplexage d'E/S pour surveiller simultanément l'état de lecture et d'écriture de plusieurs descripteurs de fichiers.

Vous pouvez le comprendre comme ayant des caractéristiques multithread.

Une fois qu'une requête réseau est reçue, elle sera traitée rapidement en mémoire. Étant donné que la plupart des opérations sont purement basées sur la mémoire, la vitesse de traitement sera très rapide.

C'est-à-dire qu'en mode monothread, même s'il y a beaucoup de traitement réseau connecté, il peut toujours être ignoré dans le traitement de la mémoire à grande vitesse en raison du multiplexage des E/S.

(2) Haute maintenabilité

Bien que le modèle multi-thread fonctionne bien, il introduira une incertitude dans l'ordre d'exécution du programme, provoquant ainsi des problèmes liés à la lecture et à l'écriture simultanées. Le mode monothread permet un débogage et des tests faciles.

(3) Basé sur la mémoire, l'efficacité est toujours élevée dans un état monothread

Le multithread peut utiliser pleinement les ressources du processeur, mais pour Redis, la vitesse basée sur la mémoire est assez élevée et peut traiter 10 Si 100 000 demandes d'utilisateurs par seconde ne sont pas satisfaites, nous pouvons alors utiliser la technologie de partitionnement Redis pour les transmettre à différents serveurs Redis. Cette méthode de cuisson évite d'introduire beaucoup d'opérations multi-thread dans le même service Redis.

À moins qu'une sauvegarde AOF ne soit requise, cette opération n'implique fondamentalement aucune opération d'E/S car elle est basée sur la mémoire. Étant donné que la lecture et l'écriture de ces données s'effectuent uniquement en mémoire, la vitesse de traitement est très rapide ; utiliser un modèle multithread pour gérer toutes les requêtes externes n'est peut-être pas une bonne solution.

Maintenant, nous savons qu'il peut se résumer en deux phrases. Basé sur la mémoire et utilisant la technologie de multiplexage, le mono-threading est très rapide et garantit les caractéristiques du multi-threading. Parce qu'il n'est pas nécessaire d'utiliser le multithreading.

3. Pourquoi le multithreading est-il introduit ?

Nous venons de mentionner les avantages du mono-threading, mais je veux maintenant expliquer pourquoi nous devons introduire le multi-threading et surmonter l'inconfort qui en découle. L'introduction du multi-threading montre que dans certains aspects de Redis, le monothreading n'a plus d'avantages.

Étant donné que les appels système de lecture/écriture pour la lecture et l'écriture sur le réseau occupent la majeure partie du temps CPU lors de l'exécution de Redis, si la lecture et l'écriture du réseau sont multithread, les performances seront grandement améliorées.

Le multithread de Redis n'est utilisé que pour la lecture et l'écriture de données réseau et l'analyse de protocole, tandis que l'exécution des commandes est toujours monothread. La raison de cette conception est que nous ne voulons pas que Redis devienne compliqué à cause du multithreading, et nous devons contrôler les problèmes de concurrence tels que les clés, Lua, les transactions, LPUSH/LPOP, etc.

Redis a ajouté certaines opérations de suppression qui peuvent être traitées de manière asynchrone par d'autres threads dans les dernières versions, c'est ce que nous avons mentionné ci-dessus

, pourquoi avons-nous besoin de ces opérations de suppression et pourquoi doivent-elles être un traitement asynchrone ? ?

UNLINK、FLUSHALL ASYNC 和 FLUSHDB ASYNCNous savons que Redis peut utiliser la commande del pour supprimer un élément. Si l'élément est très volumineux, qui peut occuper des dizaines ou des centaines de mégaoctets, il ne peut pas être terminé en peu de temps. Cela nécessite un support asynchrone multithread.

La suppression peut désormais être effectuée en arrière-plan.

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!