Pourquoi avons-nous besoin d'un pool de connexions dans node.js lorsque le noeud est mono-thread?

Question

Node.js est mono-thread. Le moteur Javascript V8 et certaines bibliothèques internes sont multi-thread. Pour les E/S, le nœud délègue les E/S à l'OS qui peut être multithread.

Si mon application node.js se connecte au serveur redis ou sql/mariadb, je suppose que je ne devrais pas avoir besoin d'un pool de connexions pour redis ou mysql. En tant que développeur, je crée 1 connexion redis ou mysql et je la réutilise pour envoyer/recevoir des données. Lorsque les données arrivent, le nœud appelle le rappel pour traiter les données.

Je comprends la mise en commun de connexions avec Java/.NET mais elles sont multi-threadées et le regroupement de connexions en Java/.NET a donc un avantage certain.

Ma question est la suivante: Pourquoi avons-nous besoin d'un pool de connexions dans node.js lorsque le noeud est mono-thread? Y a-t-il un avantage? Le noeud ne tirera-t-il pas parti des fonctionnalités multi-thread de l'OS sous-jacent et du moteur javascript sans que le développeur ne doive le faire?

Merci

Answer 1

Noeud court votre seul code fileté. Cependant, Node.js dispose en fait d'un pool de threads auquel votre code n'a pas accès. Les mécanismes de filetage sont implémentés avec libuv. Jetez un oeil à libuv book son en profondeur et explique le fonctionnement interne de libuv.

Fondamentalement, votre code est exécuté dans le contexte de la boucle d'événements (thread unique). Tout travail asynchrone est ensuite déchargé sur un thread disponible à partir du pool et la boucle d'événements est simplement interrogée jusqu'à ce que le travail asynchrone soit terminé par l'un des threads. Une fois terminé, la fonction de rappel enregistrée par votre appel asynchrone est alors invoquée et travaillée pendant la prochaine I/O Callback Phase boucle d'événement. Vous pouvez en savoir plus sur la boucle d'événements et ses phases dans le Node.js docs. L'un des avantages de la construction d'une application avec ce style de boucle d'événements est l'abstraction du codage de section critique (mutexs, sémaphores, etc.) normalement associé aux applications multithread.

Answer 2

Vous avez besoin de pools de connexions, car même un seul thread peut contenir plusieurs connexions DB «bloquantes» (en supposant le SGBDR ici). Sans pool de connexion, votre application créera chaque connexion à partir de zéro pour chaque demande de base de données supplémentaire, même dans un système asynchrone/non bloquant tel que Node.

Exemple:

request 1 - insert user -- wait for response (assume it's 5 secs) 
request 2 - insert invoice - wait for response (assume it's 3 secs) 
request 3 - insert another invoice 

Notez que demande 3 est traité immédiatement, sans attendre la demande 1 et 2 pour compléter. Juste ici dans ce fil unique, nous avons déjà utilisé trois ressources pour se connecter à la base de données. Imaginez que vous deviez créer chacun d'eux chaque fois que vous avez besoin d'une opération DB. Il est beaucoup plus rapide d'en prendre un dans un pool de connexion!