Maison > Article > interface Web > Introduction détaillée aux connaissances de base sur node js
Il y a quelques années, vous auriez peut-être hésité à apprendre NodeJS, craignant que cela ne détourne l'attention de l'apprentissage front-end. Mais maintenant, si vous n'apprenez pas nodeJS, vous ne pourrez peut-être pas progresser dans l'apprentissage front-end. Les progrès de la technologie sont si cruels. Lorsque nous attendons de voir les nouvelles technologies, la technologie est déjà devenue populaire. Cet article présentera les connaissances de base de nodeJS
Ryan Dahl est un programmeur senior C/C++ Avant de créer Node, son travail principal est centré autour de. serveurs Web hautes performances. Après quelques tentatives et échecs, il a trouvé plusieurs points clés pour concevoir des serveurs web performants : des E/S événementielles, non bloquantes, et ce sont les deux caractéristiques majeures de nodejs
Alors Ryan Dahl L'original L'objectif était d'écrire un serveur Web basé sur des E/S non bloquantes et pilotées par des événements afin d'obtenir des performances plus élevées et de fournir une alternative aux serveurs tels qu'Apache. Lors de l'écriture de Node, Ryan Dahl a évalué C, Lua, Haskell, Ruby et d'autres langages comme implémentations alternatives. Il a conclu que C a un seuil de développement élevé et qu'il est prévisible que peu de développeurs pourront l'utiliser au quotidien. Développement commercial, alors abandonnez-le ; Ryan Dahl a estimé qu'il n'était pas assez bon chez Haskell, alors il l'a abandonné ; Lua lui-même contient déjà de nombreuses bibliothèques d'E/S bloquantes, et la construction d'une bibliothèque d'E/S non bloquante ne peut pas changer les gens. utilisation continue de l'habitude de blocage des E/S. /O, elle a donc été abandonnée ; et la machine virtuelle de Ruby a été rejetée en raison de mauvaises performances
En comparaison, JavaScript a un seuil de développement inférieur à celui du C et a moins de bagages historiques. que Lua. Bien que JavaScript côté serveur existe depuis de nombreuses années, il n'y a pas de marché pour la partie back-end. On peut dire qu'il n'y a aucun bagage historique et qu'il n'y a pas de résistance supplémentaire à l'importation de bibliothèques d'E/S non bloquantes pour. il. De plus, JavaScript propose une large gamme d'applications événementielles dans les navigateurs, ce qui coïncide avec la préférence de Ryan Dahl pour les besoins événementiels. A cette époque, la deuxième guerre des navigateurs touchait progressivement à sa fin, et le moteur JavaScript V8 du navigateur Chrome remportait le titre de n°1 en termes de performances. Prenant en compte les trois principales raisons de haute performance, d'être piloté par les événements et de n'avoir aucun bagage historique, JavaScript est devenu le langage d'implémentation de Node
Au début , Ryan Dahl l'a appelé. Son projet est web.js, qui est un serveur Web. Cependant, le développement du projet a dépassé son idée originale de simplement développer un serveur Web et est devenu un cadre de base pour la création d'applications réseau. que d'autres éléments peuvent être construits dessus, tels que des serveurs, des clients, des outils de ligne de commande, etc. Node s'est développé en un système monothread et monoprocessus qui n'oblige à aucun partage de ressources. Il contient des bibliothèques très adaptées au réseau et fournit une infrastructure pour créer des applications distribuées à grande échelle. pour créer des applications réseau rapides et évolutives. En soi, il est très simple. Il organise de nombreux nœuds via des protocoles de communication et est très facile à étendre pour atteindre l'objectif de création d'applications réseau à grande échelle. Chaque processus Node constitue un nœud dans cette application réseau, ce qui est la véritable signification de son nom
En tant que plateforme d'exécution JavaScript back-end, Node conserve le interfaces familières dans le navigateur frontal JavaScript sans réécrire les fonctionnalités du langage lui-même. Il est toujours basé sur la portée et la chaîne de prototypes. La différence est qu'il migre les idées largement utilisées en front-end vers le côté serveur. Les caractéristiques de Node par rapport aux autres langages sont les suivantes
1. E/S asynchrones
Dans Node, la plupart des opérations sont appelées de manière asynchrone. Ryan Dahl a surmonté toutes les difficultés et a construit de nombreuses API d'E/S asynchrones au niveau inférieur, de la lecture de fichiers aux requêtes réseau, etc. L’importance de ceci est que dans Node, nous pouvons naturellement effectuer des opérations d’E/S parallèles à partir du niveau du langage. Il n'est pas nécessaire d'attendre la fin de l'appel d'E/S précédent entre chaque appel. Cela peut grandement améliorer l'efficacité du modèle de programmation
Prenons comme exemple l'exécution simultanée de deux tâches de lecture de fichiers. Les E/S asynchrones dépendent du temps nécessaire pour lire le fichier le plus lent, tandis que les E/S synchrones. le temps pris est la somme du temps pris par les deux tâches. Les avantages apportés par l'asynchrone ici sont évidents
2. Événements
Avec l'avènement de l'ère du Web 2.0, JavaScript a assumé davantage de responsabilités sur le front-end et les événements ont également été largement utilisés. Node n'est pas aussi fortement influencé par Java que Rhino. Au lieu de cela, il introduit dans le back-end des événements largement utilisés et matures dans les navigateurs frontaux, coopère avec les E/S asynchrones et expose les points d'événement à la logique métier
Événements La méthode de programmation présente les avantages d'être légère, flexible et de se concentrer uniquement sur les points de transaction. Cependant, dans le scénario de plusieurs tâches asynchrones, les événements sont indépendants les uns des autres et la manière de collaborer pose problème3. Fonction de rappel
Par rapport à d'autres langages de programmation web back-end, en plus des fonctions asynchrones et des événements, les fonctions de rappel sont une fonctionnalité majeure de Node. Dans l’ensemble, les fonctions de rappel constituent également le meilleur moyen d’accepter les données renvoyées par les appels asynchrones. Cependant, cette méthode de programmation peut être très peu familière à de nombreuses personnes habituées à la programmation synchrone. L’ordre dans lequel le code est écrit n’a rien à voir avec l’ordre dans lequel il est exécuté, ce qui peut leur poser des difficultés de lecture. En termes de contrôle de processus, parce que les méthodes asynchrones et les fonctions de rappel sont intercalées, cela devient moins clair que la méthode synchrone conventionnelle
4. Thread unique
Une caractéristique majeure du langage JavaScript est qu'il est monothread, ce qui signifie qu'il ne peut faire qu'une seule chose à la fois. JavaScript est monothread, selon son objectif. En tant que langage de script de navigateur, l'objectif principal de JavaScript est d'interagir avec les utilisateurs et de manipuler le DOM. Cela détermine qu'il ne peut être qu'un seul thread, sinon cela entraînera des problèmes de synchronisation très complexes. Par exemple, supposons que JavaScript ait deux threads en même temps. Un thread ajoute du contenu à un certain nœud DOM et l'autre thread supprime le nœud. Dans ce cas, quel thread le navigateur doit-il utiliser ? Par conséquent, afin d'éviter toute complexité, JavaScript est monothread depuis sa naissance, ce qui est devenu la caractéristique principale de ce langage
Node conserve les caractéristiques monothread de JavaScript dans le navigateur. Et dans Node, JavaScript ne peut partager aucun état avec d'autres threads. Le plus grand avantage du thread unique est que vous n'avez pas à vous soucier des problèmes de synchronisation d'état comme la programmation multithread. Il n'y a pas de blocage ici et il n'y a pas de surcharge de performances causée par l'échange de contexte de thread
De même, un seul thread a également ses propres faiblesses, notamment les trois aspects suivants : il ne peut pas tirer parti des processeurs multicœurs ; les erreurs entraîneront la fermeture de l'ensemble de l'application et la robustesse de l'application mérite d'être testée ; , ce qui rend impossible la poursuite des appels d'E/S asynchrones
Comme si la navigation en JavaScript sur le serveur partage le même thread que l'interface utilisateur, l'exécution à long terme de JavaScript entraînera l'interruption du rendu et de la réponse de l'interface utilisateur. Dans Node, l'utilisation à long terme du processeur empêchera également l'émission d'appels d'E/S asynchrones ultérieurs et la fonction de rappel des E/S asynchrones terminées ne sera pas exécutée à temps
HTML5 personnalise le Web. standard pour Workers, Web Workers peut créer des threads de travail pour effectuer des calculs afin de résoudre le problème des calculs JavaScript volumineux bloquant le rendu de l'interface utilisateur. Afin de ne pas bloquer le thread principal, le thread de travail fournit les résultats en cours d'exécution via le passage de messages, ce qui empêche également le thread de travail d'accéder à l'interface utilisateur dans le thread principal
Node adopte la même idée que les Web Workers pour résoudre le problème monothread Problème de calcul moyen et grand : child_process. L'émergence de sous-processus signifie que Node peut gérer sereinement les problèmes de robustesse monothread et d'incapacité à utiliser des processeurs multicœurs. En distribuant les calculs aux sous-processus individuels, un grand nombre de calculs peuvent être divisés, puis les résultats peuvent être communiqués via des messages d'événement entre les processus, ce qui permet de conserver un modèle d'application simple et peu dépendant. Grâce à la méthode de gestion Maître-Ouvrier, chaque processus de travail peut également être bien géré pour atteindre une plus grande robustesse
Lors de la sélection technologique Avant, vous devez comprendre à quels types de scénarios une nouvelle technologie est adaptée. Après tout, la bonne technologie peut avoir des effets inattendus lorsqu'elle est utilisée dans les bons scénarios. Concernant Node, les plus discutés sont ceux qui sont gourmands en E/S et en CPU
1. gourmands en E/S
Si tous les langages de script sont jugés au même endroit , alors de Dans une perspective monothread, la capacité de Node à gérer les E/S mérite d'être saluée. De manière générale, il n'y a fondamentalement aucune objection à dire que Node est bon dans les scénarios d'applications gourmands en E/S. Node est orienté réseau et bon pour les E/S parallèles, et peut organiser efficacement plus de ressources matérielles pour fournir plus de bons services
L'avantage gourmand en E/S réside principalement dans l'utilisation par Node des capacités de traitement des boucles d'événements. de démarrer chaque thread pour répondre à chaque requête, cela prend très peu de ressources
2. gourmand en CPU
D'un autre point de vue, dans les scénarios d'application gourmands en CPU, Node en est-il capable ? En fait, l'efficacité d'exécution du V8 est très élevée. À en juger par la seule efficacité d'exécution, il ne fait aucun doute que l'efficacité d'exécution du V8
Les défis que les applications gourmandes en CPU apportent à Node sont principalement : en raison de la nature monothread de JavaScript, s'il y a des calculs de longue durée (Par exemple, une grande boucle) empêchera la libération de la tranche de temps CPU, empêchant ainsi le lancement des E/S suivantes. Cependant, ajustez et décomposez de manière appropriée les tâches informatiques à grande échelle en plusieurs petites tâches afin que le calcul puisse être libéré en temps opportun sans bloquer le lancement des appels d'E/S. De cette façon, vous pouvez profiter des avantages des E/S asynchrones parallèles. O et utiliser pleinement le CPU
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!