Pourquoi dit-on que Redis est monothread ?

Redis est un service de dictionnaire distant. Il s'agit d'une base de données de valeurs-clés de type journal open source écrite en langage ANSI C, prend en charge le réseau, peut être basée sur la mémoire et persistante, et fournit API multilingue.

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

Processeur d'événements de fichiers

Redis a développé un processeur d'événements réseau basé sur le mode Reactor. traitement Le gestionnaire est appelé gestionnaire d'événements de fichier. Sa structure est composée de 4 parties : plusieurs sockets, un multiplexeur IO, un répartiteur d'événements de fichiers et un processeur d'événements. Étant donné que la consommation de la file d'attente du répartiteur d'événements de fichier est monothread, Redis est appelé un modèle monothread.

Flux de traitement des messages

Le gestionnaire d'événements de fichier utilise des procédures de multiplexage d'E/S (multiplexage) pour écouter plusieurs sockets en même temps, et différents événements les gestionnaires sont associés au socket en fonction de la tâche qu'il exécute actuellement.

Lorsque le socket surveillé est prêt à effectuer des opérations telles que la réponse de connexion (accepter), la lecture (lecture), l'écriture (écriture), la fermeture (fermeture), etc., l'événement de fichier correspondant à l'opération sera se produisent, le gestionnaire d'événements de fichier appellera le gestionnaire d'événements précédemment associé au socket pour gérer ces événements.

Bien que plusieurs événements de fichier puissent se produire simultanément, le multiplexeur d'E/S poussera toujours toutes les sockets génératrices d'événements dans une file d'attente, puis passera par cette file d'attente pour envoyer les sockets au répartiteur d'événements de fichier de manière séquentielle, synchrone, une socket à la fois : après le traitement de l'événement généré par le socket précédent (le socket est l'objet de l'événement) (le gestionnaire d'événements associé est exécuté), et le multiplexeur d'E/S continuera à envoyer le socket suivant à l'événement de fichier répartiteur.

Implémentation du multiplexeur d'E/S

Toutes les fonctions du multiplexeur d'E/S de Redis sont regroupées en sélectionnant, epoll, evport et kqueue. Il est implémenté par la bibliothèque de fonctions de multiplexage. La bibliothèque correspond à un fichier distinct dans le code source Redis, tel que ae_select.c, ae_epoll.c, ae_kqueue.c, etc.

Étant donné que Redis implémente la même API pour chaque bibliothèque de fonctions de multiplexage d'E/S, l'implémentation sous-jacente du programme de multiplexage d'E/S est interchangeable, comme le montre la figure ci-dessous.

Pour une explication détaillée d'epoll, vous pouvez cliquer pour voir et comprendre en profondeur le principe de fonctionnement efficace d'epoll

Redis dans le programme de multiplexage d'E/S La macro #include est utilisée pour définir les règles correspondantes dans le code source d'implémentation. Le programme sélectionnera automatiquement la bibliothèque de fonctions de multiplexage d'E/S la plus performante du système lors de la compilation comme implémentation sous-jacente du programme de multiplexage d'E/S de Redis :<.>

/* Include the best multiplexing layer supported by this system.
 * The following should be ordered by performances, descending. */
#ifdef HAVE_EVPORT
#include "ae_evport.c"
#else
    #ifdef HAVE_EPOLL
    #include "ae_epoll.c"
    #else
        #ifdef HAVE_KQUEUE
        #include "ae_kqueue.c"
        #else
        #include "ae_select.c"
        #endif
    #endif
#endif

Types d'événements de fichiers

Le multiplexeur d'E/S peut écouter l'événement ae.h/AE_READABLE et l'événement ae.h/AE_WRITABLE de plusieurs sockets. La correspondance entre les événements de classe et les opérations de socket est. comme suit :

Lorsque le socket devient lisible (le client effectue une opération d'écriture sur le socket, ou effectue une opération de fermeture), ou il y a un nouveau Lorsqu'un socket acceptable apparaît (le client effectue une opération de connexion sur socket d'écoute du serveur), la socket génère un événement AE_READABLE.

Lorsque le socket devient accessible en écriture (le client effectue une opération de lecture sur le socket), le socket génère l'événement AE_WRITABLE. Le multiplexeur d'E/S permet au serveur d'écouter l'événement AE_READABLE et l'événement AE_WRITABLE du socket en même temps. Si un socket génère les deux événements en même temps, le répartiteur d'événements de fichier donnera la priorité à l'événement AE_READABLE et attendra le résultat. L'événement AE_READABLE est traité. Après cela, gérez l'événement AE_WRITABLE. Cela signifie que si un socket est à la fois lisible et inscriptible, le serveur lira d'abord à partir du socket, puis écrira sur le socket.

Processeurs pour les événements de fichiers

Redis a écrit plusieurs processeurs pour les événements de fichiers. Ces processeurs d'événements sont utilisés pour implémenter différentes exigences de communication réseau :

. Afin de répondre à chaque client connecté au serveur, le serveur doit associer un gestionnaire de réponse de connexion au socket d'écoute.

Afin de recevoir la demande de commande du client, le serveur doit associer le gestionnaire de demande de commande au socket client.

Afin de renvoyer le résultat de l'exécution de la commande au client, le serveur doit associer le gestionnaire de réponse de commande au socket client.

Processeur de réponse de connexion

La fonction acceptTcpHandler dans networking.c est le processeur de réponse de connexion de Redis. Ce processeur est utilisé pour répondre au client qui se connecte au socket d'écoute du serveur. est le suivant Un wrapper pour la fonction sys/socket.h/accept.

Lors de l'initialisation du serveur Redis, le programme associera ce processeur de réponse de connexion à l'événement AE_READABLE du socket d'écoute du serveur Lorsqu'un client utilise la fonction sys/socket.h/connect pour se connecter au socket d'écoute du serveur Quand, le socket générera un événement AE_READABLE, déclenchant l'exécution du processeur de réponse de connexion et effectuera l'opération de réponse de socket correspondante, comme indiqué dans la figure.

Processeur de demande de commande

La fonction readQueryFromClient dans networking.c est le processeur de demande de commande de Redis. Ce processeur est responsable de la lecture à partir du socket. le contenu de la demande de commande envoyée par le client est spécifiquement implémenté en tant que wrapper de la fonction unistd.h/read.

Lorsqu'un client se connecte avec succès au serveur via le processeur de réponse de connexion, le serveur associera l'événement AE_READABLE du socket client au processeur de demande de commande lorsque le client envoie une demande de commande au serveur, le socket. générera un événement AE_READABLE, déclenchant l'exécution du processeur de demande de commande et effectuera l'opération de lecture de socket correspondante, comme indiqué dans la figure.

Pendant tout le processus de connexion du client au serveur, le serveur associera toujours des processeurs de requêtes de commande pour l'événement AE_READABLE du socket client.

Processeur de réponse de commande

La fonction sendReplyToClient dans networking.c est le processeur de réponse de commande de Redis. Ce processeur est chargé de renvoyer la réponse de commande obtenue par le serveur après l'exécution de la commande au client. via l'extrémité du socket, qui est spécifiquement implémentée en tant que wrapper pour la fonction unistd.h/write.

Lorsque le serveur a une réponse de commande qui doit être envoyée au client, le serveur associera l'événement AE_WRITABLE du socket client au processeur de réponse de commande lorsque le client est prêt à recevoir la réponse de commande de. le serveur, l'événement AE_WRITABLE sera généré, déclenchant l'exécution du processeur de réponse de commande et effectuant l'opération d'écriture de socket correspondante, comme le montre la figure.

Une fois la réponse de commande envoyée, le serveur dissociera le gestionnaire de réponse de commande de l'événement AE_WRITABLE du socket client.

Un exemple complet d'événement de connexion client-serveur

En supposant que le serveur Redis est en cours d'exécution, alors l'événement AE_READABLE du socket d'écoute de ce serveur doit être dans l'état d'écoute, et cet événement Le le processeur correspondant est le processeur de réponse de connexion.

Si un client Redis initie une connexion au serveur Redis à ce moment-là, le socket d'écoute générera un événement AE_READABLE, déclenchant l'exécution du processeur de réponse de connexion : le processeur répondra à la demande de connexion du client, puis create Le socket client, ainsi que l'état du client, et associe l'événement AE_READABLE du socket client au processeur de demande de commande afin que le client puisse envoyer une demande de commande au serveur principal.

Après cela, le client envoie une requête de commande au serveur Redis, puis le socket client générera un événement AE_READABLE, déclenchant l'exécution du processeur de requête de commande. Le processeur lit le contenu de la commande du client puis le transmet. au programme concerné à exécuter.

L'exécution des commandes générera les réponses de commande correspondantes. Afin de transmettre ces réponses de commande au client, le serveur associera l'événement AE_WRITABLE du socket client au gestionnaire de réponse de commande : lorsque le client tente de lire When. la commande répond, le socket client générera un événement AE_WRITABLE, déclenchant l'exécution du processeur de réponse de commande écrit toutes les réponses de commande sur le socket, le serveur libérera l'AE_WRITABLE du socket client Association entre les événements. et les gestionnaires de réponse aux commandes.

Recommandations associées : Tutoriel sur la base de données Redis

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!