Vous faire comprendre les E/S asynchrones non bloquantes dans Nodejs

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

[Recommandations de didacticiel associées : Tutoriel vidéo Nodejs, Enseignement de la programmation]

Nous prenons l'exemple d'E/S de demande réseau, introduisons d'abord le processus typique du serveur traitant une demande d'E/S réseau complète :

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

• Attendre que les données soient prêtes

• Copier les données du noyau vers le processus

Ci-dessous, nous prenons la fonction recvfrom comme un exemple pour expliquer divers modèles d'IOs

Blocking I/OModèle (blocage d'E/S)

Blocking call signifie qu'avant que le résultat de l'appel ne soit renvoyé, le thread actuel sera suspendu et le thread appelant peut attendez seulement toutes les opérations au niveau du noyau du système L'appel ne se terminera pas tant qu'il ne sera pas terminé.

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 lorsqu'il y a des données qui peuvent l'être. Lecture ou écriture des 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 aux performances de sélection, elle est légèrement améliorée

• . 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 que l'événement se produise et que le thread se réveille. Il tire vraiment parti des notifications d'événements et exécute des rappels au lieu de parcourir des requêtes (descripteur de fichier), donc aucun processeur n'est gaspillé

Résumé : Essentiellement, L'interrogation est toujours une opération synchrone, car l'application attend toujours le retour complet des E/S. Pendant la période d'attente, elle traverse l'état de description du fichier ou 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, principalement des E/S modèle de réutilisation.

Sous Windows, de véritables E/S asynchrones sont implémentées 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 + une interrogation, permettant un Les threads uniques effectuent des calculs et transfèrent 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 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 plate-forme * nix ou Windows, la couche inférieure utilise un 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!