Analyse du processus de traitement des événements Redis

Avant-propos :

Nous savons que le serveur Redis est un programme piloté par les événements, qui doit gérer deux types d'événements, à savoir les événements de fichiers et les événements temporels.

Alors, à quoi ressemble le processus de traitement des événements Redis ? Jetons un coup d'œil à l'image ci-dessous :

La fonction aeMain planifie et exécute les événements de fichier et les événements temporels en appelant la fonction aeProcessEvents. Les informations relatives à l'événement sont enregistrées dans aeEventLoop. Tout d'abord, obtenez l'intervalle de temps d'exécution n de l'événement temporel le plus court via la fonction aeSearchNearestTimer, puis appelez la fonction aeApiPoll pour obtenir le socket surveillé, et enfin exécutez les fonctions de traitement d'événements rfileProc et wfileProc correspondant au socket, et enfin exécutez l'événement temporel function processTimeEvents

Événement de fichier

Redis a développé son propre processeur d'événements réseau basé sur le modèle Reactor. Ce processeur est appelé gestionnaire d'événements de fichier :

• Le gestionnaire d'événements de fichier utilise un multiplexeur IO pour écouter plusieurs sockets et associer différents gestionnaires d'événements au socket en fonction de la tâche actuellement effectuée par le socket

• Lorsque le socket surveillé est prêt à effectuer des opérations telles que la réponse de connexion (accepter), lire (lire), écrire (écrire), fermer (fermer), etc., lorsqu'un événement de fichier se produit, ces événements de fichier Le processeur appellera le gestionnaire d'événements précédemment associé au socket pour gérer l'événement

tutoriel vidéo redis)

• Processeur de réponse de connexion : lorsque le serveur Redis est initialisé, le programme associera ce processeur de réponse de connexion à l'événement AE_READABLE du package d'écoute de service Lorsqu'un client utilise la fonction connect pour se connecter au socket d'écoute du serveur Oui, le socket générera un événement AE_READABLE, déclenchera l'exécution du processeur de réponse de connexion, et effectuez l'opération de réponse de socket correspondante

• processeur de demande de commande : lorsqu'un client se connecte Une fois que le processeur de réponse se connecte avec succès au serveur, 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ère un événement AE_READABLE et déclenche la demande de commande. Le processeur exécute et effectue l'opération de lecture de socket correspondante

• . Processeur de réponse de commande : lorsque le serveur a une réponse de commande qui doit être transmise au client, le serveur prend en charge le client. L'événement AE_WRITABLE de l'interface est associé au processeur de réponse de commande lorsque le client est prêt à recevoir la réponse de commande. depuis 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

<.>

Le serveur écoute l'événement AE_READABLE du mot du package, et génère AE_READABLE lorsque le client envoie un événement de demande de connexion, le serveur répondra à la demande de connexion du client, associera l'événement AE_READABLE du socket client avec le processeur de demande de commande, et le client peut envoyer une demande de commande au serveur
Le client envoie une demande de commande au serveur Le socket client générera un événement AE_READABLE, déclenchant le. processeur de commande à exécuter. L'exécution de la commande générera une réponse de commande correspondante. Le serveur combinera l'événement AE_WRITABLE du socket client avec l'association du processeur de réponse
lorsque le client essaiera. Après avoir lu la réponse de la commande, le socket client générera un événement AE_WRITABLE, déclenchant l'exécution du processeur de réponse à la commande. Lorsque le processeur de réponse à la commande répondra à la commande, une fois que tout sera écrit sur le socket, le serveur contactera l'association entre l'événement AE_WRITABLE. du socket client et du gestionnaire de réponse de commande
Événement temporel

Les événements Redis Time sont divisés en événements chronométrés et événements périodiques. Un événement temporel se compose de trois attributs :

id : un identifiant globalement unique créé par le serveur pour l'heure et l'heure où : l'heure d'arrivée de l'heure et de l'heure est enregistrée (horodatage UNIX avec une précision de la milliseconde) timeProc : processeur d'événements temporels

Tous les événements temporels du serveur sont placés dans une liste chaînée non ordonnée. Chaque fois que l'exécuteur d'événements temporels s'exécute, il parcourt l'intégralité de la liste chaînée, trouve tous les événements temporels arrivant et appelle le gestionnaire d'événements correspondant. Le serveur Redis en mode normal n'utilise qu'un seul événement temporel, serverCron, et en mode benchmark, le serveur n'utilise que deux événements temporels, les performances d'exécution de l'événement ne sont donc pas affectées.

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!