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
Ci-dessous, nous prenons la fonction recvfrom
comme un exemple pour expliquer divers modèles d'IOs
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.
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éepolling Plusieurs stratégies d'interrogation courantes sont les suivantes
select
poll
. epoll/kqueue
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. .
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).
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.
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.
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!