Une compréhension préliminaire des E/S asynchrones dans Nodejs

Cet article vous donnera une compréhension préliminaire des E/S asynchrones dans Nodejs. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il sera utile à tout le monde.

Le terme « asynchrone » est en fait né avant Node. Mais dans la plupart des langages de programmation de haut niveau, l’asynchronie est rare. Parmi de nombreux langages ou plates-formes d'exploitation de haut niveau, Node est le premier à utiliser l'asynchrone comme principale méthode de programmation et concept de conception. [Recommandations associées : "Tutoriel nodejs"]

Les E/S asynchrones, pilotées par les événements et monothread constituent la note clé de Node, et la conception des E/S événementielles et asynchrones de Nginx et Node Les concepts sont relativement similaires. Nginx est écrit en C pur, offre d'excellentes performances et possède la puissante capacité de gérer les connexions des clients, mais il est toujours limité par divers langages de programmation de synchronisation. Mais Node est polyvalent. Il peut être utilisé comme serveur pour gérer un grand nombre de requêtes simultanées apportées par les clients, et il peut également être utilisé comme client pour effectuer des requêtes simultanées vers diverses applications du réseau.

Pourquoi les E/S asynchrones

---

Pourquoi les E/S asynchrones sont si importantes dans Node C'est parce que Node est conçu pour le réseau sous la structure ? , la concurrence est devenue une fonctionnalité standard de la programmation moderne.

Expérience utilisateur

Il est mentionné dans "JavaScript haute performance" que si le temps d'exécution du script dépasse 100 millisecondes, l'utilisateur aura l'impression que le la page est bloquée. Je pense que la page a cessé de répondre. Dans le modèle B/S, les limitations de vitesse du réseau causent de gros problèmes pour l’expérience en temps réel des pages Web.

Si la page Web a temporairement besoin d'obtenir une ressource et de l'obtenir de manière synchrone, alors JavaScript doit attendre que la ressource soit complètement obtenue du serveur avant de pouvoir continuer à s'exécuter. Pendant cette période, l'interface utilisateur se met en pause. et ne répond pas à l'interaction de l'utilisateur. Cette expérience utilisateur sera extrêmement mauvaise. Avec les requêtes asynchrones, lors du téléchargement des ressources, l'exécution de JavaScript et de l'interface utilisateur ne sera pas en état d'attente et pourra continuer à répondre aux interactions des utilisateurs.

De même, le front-end peut éliminer le blocage de l'interface utilisateur grâce à une utilisation asynchrone, mais la vitesse à laquelle le front-end obtient les ressources dépend également de la vitesse de réponse du back-end. Si une ressource provient du retour de données de deux emplacements différents, la première ressource consomme M millisecondes et la seconde ressource consomme N millisecondes. Si la méthode de synchronisation est utilisée, le temps consommé pour obtenir les deux ressources est de M+N millisecondes. Dans la méthode asynchrone, l'acquisition de la première ressource ne bloque pas l'acquisition de la deuxième ressource, et le temps consommé est max(M,N).

À mesure que le site Web ou l'application continue de se développer, les valeurs de M et N augmenteront de manière linéaire et les performances asynchrones seront plus supérieures que synchrones.

Allocation des ressources

Supposons qu'il existe un ensemble de tâches non liées qui doivent être accomplies dans le scénario commercial. Il existe deux méthodes principales :

Un seul thread s'exécute en série à la fois
• Plusieurs threads exécutés en parallèle

Si le coût de création de plusieurs threads est inférieur à celui d'une exécution parallèle, le multithreading est préférable, mais le multithread nécessite plus d'efforts dans la création de threads et la surcharge du changement de contexte de thread pendant l'exécution est relativement importante, et la programmation multithread est souvent confrontée à des problèmes tels que les verrous et la synchronisation des états.

L'inconvénient de l'exécution séquentielle monothread des tâches est la performance. Toute tâche légèrement plus lente entraînera le blocage de l'exécution ultérieure du code. Dans les ressources informatiques, les calculs d'E/S et de CPU peuvent généralement être exécutés en parallèle, mais le modèle de programmation synchrone oblige les E/S à attendre les tâches suivantes, ce qui entraîne une mauvaise utilisation des ressources.

Node utilise un seul thread pour éviter les blocages multi-threads, la synchronisation d'état et d'autres problèmes ; il utilise des E/S asynchrones pour éviter qu'un seul thread ne se bloque et utilise mieux le processeur.

Implémentation des E/S asynchrones

---

Les E/S asynchrones sont les plus largement utilisées dans Node, mais elles ne sont pas originales de Node.

E/S asynchrones et E/S non bloquantes

Pour les E/S du noyau de l'ordinateur, asynchrone/synchrone et bloquant/non bloquant sont deux des choses différentes.

Le système d'exploitation ne dispose que de deux méthodes d'E/S : bloquantes et non bloquantes. Lors de l’appel d’E/S bloquantes, l’application doit attendre la fin de l’E/S avant de renvoyer le résultat.

Une caractéristique du blocage des E/S est qu'après l'appel, l'appel doit attendre que toutes les opérations soient terminées au niveau du noyau du système avant la fin de l'appel. Le blocage des E/S oblige le processeur à attendre les E/S, ce qui fait perdre du temps d'attente et la puissance de traitement du processeur ne peut pas être pleinement utilisée.

Pour améliorer les performances, le noyau fournit des E/S non bloquantes. La différence entre les E/S non bloquantes et les E/S bloquantes est qu'elles reviendront immédiatement après le retour des E/S non bloquantes, la tranche de temps CPU peut être utilisée pour traiter d'autres choses. L'amélioration des performances est évidente, mais en raison de l'achèvement des E/S, les E/S ne sont pas terminées et ce qui est immédiatement renvoyé ne sont pas les données attendues par la couche métier, mais uniquement l'état d'appel actuel.

Afin d'obtenir des données complètes, l'application doit appeler l'opération d'E/S à plusieurs reprises pour confirmer si elle est terminée. Cette technique d'appel répété pour déterminer si une opération est terminée est appelée

Polling.

Les technologies de sondage existantes incluent principalement read, select, poll, epoll et kqueue. Ici, je ne parlerai que du principe de sondage d'epoll.

epoll est le mécanisme de notification d'événements d'E/S le plus efficace sous Linux. Lors de l'interrogation, si aucun événement d'E/S n'est détecté, il se mettra en veille jusqu'à ce qu'un événement se produise pour le réveiller. Il utilise véritablement des méthodes de notification d'événements et de rappel d'exécution au lieu de parcourir des requêtes, de sorte qu'il ne gaspille pas de CPU et offre une efficacité d'exécution plus élevée.

La technologie d'interrogation répond au besoin d'E/S non bloquantes pour garantir l'obtention de données complètes, mais pour le programme, elle est toujours considérée comme une sorte de synchronisation, car l'application a encore besoin d'attendre le retour complet des E/S, cela prend encore beaucoup de temps d'attente. En attendant, le processeur est soit utilisé pour parcourir les descripteurs de fichiers, soit en veille en attendant que le moment soit venu.

E/S asynchrones réalistes

Acquisition complète des données en laissant certains threads effectuer des E/S bloquantes ou des E/S non bloquantes ainsi qu'une technologie d'interrogation, permettant à un thread d'effectuer calculs et transférer les données obtenues à partir des E/S via la communication entre les threads, ce qui implémente facilement les E/S asynchrones (bien que cela soit simulé)

Mais au départ, Node était dans *nix La plateforme utilise libeio et libev pour implémenter La partie E/S et réaliser des E/S asynchrones. Dans Node v0.9.3, un pool de threads est implémenté pour effectuer des E/S asynchrones.

L'IOCP sous Windows fournit dans une certaine mesure les E/S asynchrones de Li Xiang : appeler des méthodes asynchrones, attendre une notification une fois les E/S terminées et exécuter des rappels. Mais ses composants internes sont toujours basés sur le principe du pool de threads. La différence est que ces pools de threads sont gérés par le noyau du système.

En raison de la différence entre la plateforme Windows et la plateforme *nix, Node fournit libuv comme couche d'encapsulation abstraite, de sorte que tous les jugements de compatibilité de la plateforme soient complétés par cette couche, et assure la personnalisation du Node supérieur et du Node inférieur. Le pool de threads et l’IOCP sont complètement indépendants.

Nous mentionnons souvent que Node est mono-thread ici, c'est simplement que JavaScript est exécuté dans un seul thread. Dans Node, qu'il s'agisse de la plate-forme * nix ou Windows, il existe un pool de threads qui effectue les tâches d'E/S en interne.

E/S asynchrones du nœud

---

Complétez l'intégralité du lien d'E/S asynchrone avec des boucles d'événements, des observateurs et des objets de requête.

Boucle d'événements

La boucle d'événements est le propre modèle d'exécution de Node, ce qui rend les fonctions de rappel très courantes.

Lorsque le processus démarre, Node créera une boucle similaire à while(true). Chaque fois que le corps de la boucle est exécuté, nous l'appelons Tick. Le processus de chaque Tick consiste à vérifier s'il y a un événement à traiter et, si c'est le cas, à récupérer l'événement et sa fonction de rappel associée. Si des fonctions de rappel associées existent, exécutez-les. Entrez ensuite dans la boucle suivante, et s'il n'y a plus d'événements à gérer, quittez le processus.

Observateur

Il y a un ou plusieurs observateurs dans chaque boucle d'événements, et il est utilisé pour déterminer s'il y a des événements à être traité Le processus consiste à demander à ces observateurs s'il y a des événements à traiter.

Dans Node, les événements proviennent principalement de requêtes réseau, d'E/S de fichiers, etc. Les observateurs correspondant à ces instants incluent les observateurs d'E/S de fichiers, les observateurs d'E/S de réseau, etc. Les observateurs ont catégorisé les événements.

La boucle événementielle est un modèle producteur/consommateur typique. Les E/S asynchrones, les requêtes réseau, etc. sont les producteurs d'événements, fournissant constamment différents types d'événements à Node. Ces événements sont transmis aux observateurs correspondants, et la boucle d'événements récupère les événements des observateurs et les traite.

Objet de requête

Pour les appels d'E/S asynchrones de Node, la fonction de rappel n'est pas appelée par le développeur. Dans le processus de transition entre le moment où JavaScript lance un appel et le moment où le noyau termine une opération d'E/S, il existe un produit appelé Request Object

La méthode fs.open() est utilisée ci-dessous comme petit exemple.

fs.open = function(path,flags,mode,callback){
    //...
    binding.open(pathModule._makeLong(path),
                    stringToFlags(flags),
                    mode,
                    callback);
}

La fonction de fs.open() est d'ouvrir un fichier selon le chemin et les paramètres spécifiés pour obtenir un descripteur de fichier. Il s'agit de l'opération préliminaire pour toutes les opérations d'E/S ultérieures. Le code de niveau JavaScript effectue des opérations de niveau inférieur en appelant le module principal C++.

JavaScript appelle le module principal de Node. Le module principal appelle le module C++ et le module intégré effectue des appels système via libuv. Nœud. Ici, libuv sert de couche d'encapsulation et a deux implémentations de plate-forme, qui appellent essentiellement la méthode uv_fs_open(). Pendant le processus d'appel de uv_fs_open(), les paramètres transmis depuis la couche JavaScript et la méthode actuelle sont encapsulés dans un objet de requête, et la fonction de rappel est définie sur les propriétés de cet objet. Une fois l’objet empaqueté, il est poussé dans le pool de threads pour attendre son exécution.

À ce stade, l'appel JavaScript revient immédiatement et la première phase de l'appel asynchrone initié par le niveau JavaScript se termine. Les threads JavaScript peuvent continuer à effectuer des opérations ultérieures sur la tâche en cours.

L'objet de requête est un produit intermédiaire important dans le processus d'E/S asynchrone. Tous les états sont enregistrés dans cet objet, y compris l'envoi au pool de threads pour attendre l'exécution et le traitement de rappel une fois l'opération d'E/S terminée.

Rappel d'exécution

Assemblez l'objet de requête et envoyez-le au pool de threads d'E/S pour exécution. Il ne termine que la première partie d'une E/S. la notification de rappel est la première partie deux.

Une fois l'opération d'E/S dans le pool de threads appelée, le résultat obtenu sera stocké dans l'attribut req->result, puis PostQueueCompletionStatus() sera appelé pour informer IOCP que l'opération d'objet en cours a été complété.

À ce stade, tout le processus d'E/S asynchrone est complètement terminé.

La boucle d'événements, l'observateur, l'objet de requête et le pool de threads d'E/S constituent ensemble les éléments de base du modèle d'E/S asynchrone Node.

Résumé

Après le tri, nous pouvons extraire plusieurs mots-clés d'E/S asynchrones : thread unique, boucle d'événements, observateur et pool de threads d'E/S. Un seul thread et un pool de threads semblent être un peu un paradoxe. JavaScript étant monothread, il est facile de comprendre qu’il ne peut pas tirer pleinement parti des processeurs multicœurs. En fait, dans Node, sauf que JavaScript est monothread, Node lui-même est en fait multithread, mais le thread d'E/S utilise moins de CPU. De plus, sauf que le code utilisateur ne peut pas être exécuté en parallèle, toutes les E/S (E/S disque, E/S réseau, etc.) peuvent être exécutées en parallèle.

Pour plus de connaissances sur la programmation, veuillez visiter : Vidéo de programmation ! !

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!