Quelle est la différence entre l'architecture événementielle de Node.js et la programmation multi-thread dans d'autres langages?


Réponse 1:

Tant dans le paradigme événementiel que multithread, le code s'exécute dans un processus de système d'exploitation.

Lorsque le processus exécute plusieurs threads, ces threads partagent la mémoire de processus (espace d'adressage) à la fois pour la lecture et l'écriture.

Le JavaScript qui alimente Node.js est monothread par conception. L'exécution de chaque fonction est garantie jusqu'à son terme, et aucun autre code JavaScript du processus en cours ne s'exécutera pendant l'exécution de cette fonction. Les événements naturellement asynchrones (réseau, entrée-sortie disque, temporisateurs, autres événements matériels et système d'exploitation) sont gérés par le moteur qui ajoute les fonctions JavaScript enregistrées en tant que gestionnaires (ou rappels) pour ces événements à la file d'attente de boucle d'événements à exécuter après les fonctions devant la file d'attente sont terminées.

Dans le paradigme multithread, deux threads ou plus exécutent du code en parallèle.Par conséquent, lors d'une exécution de fonction, un morceau de code différent peut également s'exécuter sur un cœur de processeur différent, éventuellement en lecture ou en écriture dans les mêmes adresses mémoire. Cela peut entraîner un état incohérent de la mémoire, sauf si des mécanismes spéciaux du système d'exploitation (primitives de synchronisation) sont utilisés par le code pour gérer l'accès à la mémoire partagée.



Réponse 2:

C'est une bonne question, "Quelle est la différence entre l'architecture pilotée par les événements de Node.js et la programmation multithread dans d'autres langages?".

Nous pouvons et devons décomposer cela un peu.

  • L'architecture événementielle du nœud.

L'architecture pilotée par les événements n'est pas exclusive à Node, par exemple, Tornado (Python), Vertx (Java), Akka (Scala), ReactiveX (plusieurs langues).

  • Programmation multi-thread dans d'autres langues.

Notez que JavaScript, de par sa conception, ne prend pas en charge plusieurs threads. Bien qu'il supporte les webworkers, qui, pour autant que je sache, peuvent fonctionner comme des threads.

Par conséquent, l'événementiel n'est pas propre à Node et le multithread peut être effectué dans Node.

Il peut donc y avoir deux questions ici: "Quelle est la différence entre événementiel et multi-threading", et "Quelle est la différence entre Node et d'autres langages (frameworks)". Je vais me concentrer sur ce dernier car cela semble être l’intention de la question.

Je dirais que ce qui rend Node spécial, c'est que l'auteur l'a créé dans le but d'éviter de bloquer les E / S lors de la création d'applications Web. La culture de la communauté Node est de mettre l'accent sur la force des E / S non bloquantes et de les renforcer. Vous ne trouverez pas trop de bibliothèques tierces qui bloquent les appels. En tant que développeur utilisant Node, il est peu probable que vous rencontriez des opérations de blocage subtiles dans votre code. Alors que dans d'autres langues, un développeur naïf peut accidentellement effectuer des appels de blocage très inefficaces comme la lecture d'une connexion à une base de données.

En dehors de cela, vous devriez vraiment lire sur plusieurs modèles de «simultanéité» et comprendre les avantages et les inconvénients de chacun. Points bonus pour avoir apprécié pourquoi le multi-threading était acceptable pendant si longtemps.



Réponse 3:

les différences conceptuelles sont assez faciles à comprendre.

Dans une architecture pilotée par les événements, votre programme s'exécute dans une boucle continue unique (vous pouvez faire du multithread dans le nœud, mais ne vous inquiétez pas pour le moment). Lorsqu'un événement se déclenche, un travail est sur la pile d'appels pour être traité aux loisirs du programme.

L'architecture multithread envoie généralement un nouveau thread quand il doit attendre une action. Donc, vous appelez une base de données et vous faites tourner un nouveau thread qui exécutera toutes les choses dont vous avez besoin et fera ce dont vous avez besoin et conclura ou rejoindra le thread d'origine.

Ces deux méthodes sont très utiles pour différentes choses. L'événement piloté est idéal pour l'interface utilisateur et les serveurs car votre programme ne sait pas quand un nouveau even se produira et souvent les événements arriveront en rafales. Bien que le filetage soit nécessaire pour les travaux lourds en termes de calcul où vous souhaitez diviser un problème en morceaux beaucoup plus petits (ou si vous approchez de la limite de votre boucle filetée unique).