Node.js

Par alouragli, 20 février, 2025
Node.js

Le modèle Single Thread non-bloquant

Du modèle Multi-Threads(multi-tâches) bloquant au modèle Single Thread(mono-tâche) non-bloquant

Avant la création de Node.js, les applications utilisaient le modèle Multi-Threads bloquant. Ce modèle repose sur plusieurs threads d'exécution, chaque requête étant traitée par un thread distinct. Bien que cette approche fonctionne bien dans de nombreux cas, elle présente un inconvénient majeur : chaque thread doit attendre la fin d'une opération avant de passer à la suivante.

Par exemple, lorsqu'un serveur traite une requête, il doit d'abord lire les données, puis accéder à la base de données, interroger des services distants et enfin envoyer une réponse. À chaque étape, il reste bloqué en attente de la réponse, ce qui ralentit le traitement général. Si le nombre de requêtes dépasse la capacité des threads disponibles, le service devient lent, voire indisponible, rendant l'application inefficace, surtout en cas de connexions lentes ou de latences variables entre les utilisateurs.

Face à cette limite, une question s’est posée : Peut-on gérer plusieurs requêtes efficacement avec un nombre réduit de threads et un traitement non bloquant des entrées-sorties ?

L’apparition du modèle Single Thread non-bloquant avec Node.js

C’est ainsi que Node.js a été conçu, reposant sur un patron de conception appelé Reactor. Un patron de conception est une solution réutilisable qui améliore la structure et la maintenabilité du code. Le Reactor pattern repose sur une boucle d’événements (event loop) qui permet à un seul thread, appelé IO Selector Thread, de gérer plusieurs requêtes simultanément sans être bloqué.

Contrairement au modèle Multi-Threads, où chaque requête bloque un thread, le modèle Single Thread non-bloquant de Node.js fonctionne de manière asynchrone :

L'IO Selector Thread reçoit toutes les requêtes. Pour chaque requête, il crée un événement et continue immédiatement à traiter d’autres tâches. Lorsqu'une opération (comme la lecture d’une base de données) est terminée, un worker thread exécute la suite du traitement sans bloquer l’application. Un bon exemple pour comprendre ce fonctionnement est la différence entre un appel téléphonique et un SMS :

Un appel téléphonique est synchrone : on pose une question et on attend la réponse avant de raccrocher. Un SMS est asynchrone : on envoie un message et on peut faire autre chose en attendant la réponse, qui arrivera sous forme de notification.

Optimisation avec les Worker Threads et la scalabilité

Bien que le modèle Single Thread soit efficace, un seul thread ne peut pas tout gérer. Pour améliorer les performances, Node.js utilise des Worker Threads. Ces threads supplémentaires sont appelés par le thread principal et sont limités au nombre de cœurs du processeur. Leur rôle est de traiter certaines tâches complexes tout en maintenant le modèle non bloquant.

Lorsqu'une application devient très sollicitée et qu'un seul thread principal ne suffit plus, on applique un principe appelé scalabilité :

Dès que le nombre d’utilisateurs dépasse un seuil critique, une nouvelle machine démarre avec d'autres Worker Threads. Ce mécanisme d’extension automatique permet au système de s’adapter à la charge sans mobiliser trop de ressources dès le départ. Ce modèle est élastique et performant, contrairement au modèle Multi-Threads qui mobilise immédiatement plusieurs threads et devient inefficace à grande échelle.

Conclusion

Node.js a révolutionné le développement en étant la première technologie à exploiter pleinement le modèle Single Thread non-bloquant avec le patron de conception Reactor. Aujourd’hui, d’autres technologies ont adopté cette approche en proposant également la programmation réactive et en offrant le choix entre les deux modèles selon les besoins.

Enfin, Node.js repose sur V8, le moteur JavaScript de Chrome, qui optimise l’exécution des applications, renforçant ainsi sa rapidité et son efficacité pour des applications légères et réactives comme les jeux en ligne ou les chats en temps réel.

Références

Commentaires