Parlons des différents modèles d'E/S dans Node

Cet article parlera des différents modèles d'E/S dans Node et présentera le modèle d'E/S bloquantes, le modèle d'E/S non bloquantes et les E/S asynchrones non bloquantes. J'espère qu'il sera utile à tout le monde. .

Prenons l'exemple d'une requête réseau IO. Tout d'abord, nous introduisons le processus typique du serveur traitant une requête réseau complète :

L'application obtient un résultat d'opération, qui comprend généralement deux étapes différentes :

• En attente que les données soient prêtes

• Copier les données du noyau vers le processus

Ci-dessous, nous prenons la fonction recvfrom comme exemple pour expliquer les différents modèles d'E/S

Blocage E/S modèle (blocage des E/S)

Appel bloquant signifie que le thread actuel sera suspendu avant que le résultat de l'appel ne soit renvoyé, et le thread appelant ne se terminera qu'après avoir attendu que toutes les opérations au niveau du noyau du système soient terminées .

Le blocage des E/S oblige le CPU à attendre les E/S et gaspille des tranches de temps CPU.

Modèle d'E/S non bloquantes (E/S non bloquantes)

Par rapport à l'ancien,

E/S non bloquantesretourne directement sans données Pour obtenir des données, vous devez également passer un. descripteur de fichier Après avoir essayé de lire à nouveau les données

appel non bloquant

et d'avoir obtenu le retour (et non les données réellement attendues), la tranche de temps CPU peut être utilisée pour traiter d'autres choses, ce qui peut améliorer considérablement les performances. Mais le problème qui en découle est que l'opération précédente n'était pas une E/S complète et que le résultat renvoyé n'était pas les données métier attendues, mais uniquement l'état de l'appel asynchrone.

Afin d'obtenir des données complètes, l'application doit appeler à plusieurs reprises l'opération IO pour confirmer si l'opération est terminée. Cette opération est appelée

polling

Plusieurs stratégies d'interrogation courantes sont les suivantes

Busy polling

. Il s'agit de la méthode la plus primitive et la moins performante. Elle vérifie l'état des E/S via des appels répétés pour obtenir des données complètes.

Avantages : Programmation simple

Inconvénients : Le processeur est toujours consommé lors de l'interrogation. performances, car le serveur doit toujours répondre après votre interrogation

Modèle de multiplexage d'E/S (multiplexage d'E/S)

Dans le modèle de multiplexage d'E/S, fonction Select ou Poll ou fonction Epoll (prise en charge par le noyau Linux après 2.6), ces deux fonctions bloqueront également le processus, mais elles sont différentes du blocage des E/S.

Ces trois fonctions peuvent bloquer plusieurs opérations d'E/S en même temps et peuvent détecter les fonctions d'E/S de plusieurs opérations de lecture et de plusieurs opérations d'écriture en même temps. Elles ne sont réellement appelées que lorsque les données sont lisibles ou inscriptibles. Fonctions d'opération d'E/S.

Les différences entre les trois mécanismes de multiplexage d'E/S sont les suivantes

• select

Étant donné que select utilise un tableau de 1024 longueurs pour stocker l'état des fichiers, jusqu'à 1024 descripteurs de fichiers peuvent être détectés en même temps. time

• poll

est légèrement améliorée par rapport à select L'utilisation de la liste chaînée évite la limite de longueur de 1024 et évite les contrôles de parcours inutiles Par rapport à select, les performances sont légèrement améliorées

• . epoll/kqueue

est le mécanisme de notification d'événement d'E/S le plus efficace sous Linux. Si aucun événement d'E/S n'est détecté pendant l'interrogation, il

se mettra en veille

jusqu'à ce qu'un événement se produise et que le thread se réveille. Il profite vraiment des notifications d'événements et exécute des rappels au lieu de parcourir des requêtes (descripteur de fichier), donc il ne gaspille pas de CPU

Résumé : Essentiellement,

l'interrogation est toujours une opération synchrone

, car l'application Le programme est toujours en attendant le retour complet de l'E/S. Pendant la période d'attente, soit il traverse l'état de description du fichier, soit il se met en veille pour attendre que l'événement se produise.

Modèle d'E/S piloté par signal (E/S piloté par signal)

Dans le modèle d'E/S piloté par signal, l'application utilise des signaux pour piloter les E/S et installe une fonction de traitement du signal. Le processus continue de s'exécuter sans blocage.

Lorsque les données sont prêtes, le programme recevra un signal SIGIO et pourra appeler la fonction d'opération E/S dans la fonction de traitement du signal pour traiter les données.

Résumé : jusqu'à présent, le modèle d'E/S piloté par signal est plus conforme à nos besoins asynchrones. Le programme exécutera d'autres logiques métier de manière asynchrone en attendant les données.

Mais ! ! ! Il est toujours bloqué lors du processus de copie des données du noyau vers l'espace utilisateur, ce qui n'est pas une révolution complète (asynchrone).

E/S asynchrones non bloquantes idéales (nœuds)

Notre E/S asynchrone idéale devrait être un appel non bloquant lancé par l'application, sans qu'il soit nécessaire d'obtenir des données via une interrogation, et il n'est pas nécessaire de copier le données dans l'étape Au lieu d'attendre inutilement, une fois les E/S terminées, elles peuvent être transmises à l'application via une fonction de signal ou de rappel, pendant laquelle l'application peut exécuter une autre logique métier.

E/S asynchrones réelles

En fait, la plate-forme Linux prend en charge nativement les E/S asynchrones (AIO), mais actuellement AIO n'est pas parfait, donc lors de la mise en œuvre d'une programmation réseau à haute concurrence sous Linux, c'est principalement moi /O modèle de réutilisation.

Les véritables E/S asynchrones sont implémentées sous Windows via IOCP.

Simulation multithread d'E/S asynchrones

Sous la plate-forme Linux, Node utilise le pool de threads pour terminer l'acquisition de données en laissant certains threads effectuer des E/S bloquantes ou des E/S non bloquantes + interrogation, de sorte que un seul thread effectue des calculs et transfère les résultats d'E/S via la communication entre les threads, réalisant ainsi la simulation d'E/S asynchrones.

En fait, la couche inférieure de la solution asynchrone et asynchrone IOCP sous la plateforme Windows est également implémentée à l'aide d'un pool de threads. La différence est que le pool de threads de cette dernière est hébergé par le noyau système.

Nous disons souvent que Node est monothread, mais en fait, on peut seulement dire que JS est exécuté dans un seul thread Qu'il s'agisse d'une plateforme *nix ou Windows, la couche inférieure utilise le pool de threads. pour terminer les opérations d’E/S.

Pour plus de connaissances sur les nœuds, veuillez visiter : tutoriel Nodejs !

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!