À l'intérieur de la boucle d'événements Node.js : une plongée approfondie

Exploration de modèles à thread unique Node.js

Node.js adopte l'approche d'E/S asynchrone et basée sur les événements, permettant d'obtenir un environnement d'exécution JavaScript à thread unique et hautement simultané. Puisqu'un seul thread signifie qu'une seule chose peut être faite à la fois, comment Node.js atteint-il une concurrence élevée et des E/S asynchrones avec un seul thread ? Cet article explorera le modèle monothread de Node.js autour de cette question.

Stratégies à haute concurrence

Généralement, la solution pour une concurrence élevée est de fournir un modèle multithread. Le serveur attribue un thread à chaque demande client et utilise des E/S synchrones. Le système compense le coût en temps des appels d’E/S synchrones grâce à la commutation de threads. Par exemple, Apache utilise cette stratégie. Étant donné que les opérations d'E/S prennent généralement du temps, il est difficile d'atteindre des performances élevées avec cette approche. Cependant, il est très simple et peut mettre en œuvre des logiques d'interaction complexes.

En fait, la plupart des serveurs Web n'effectuent pas beaucoup de calculs. Après avoir reçu les requêtes, ils transmettent les requêtes à d'autres services (comme la lecture de bases de données), puis attendent le retour des résultats et enfin envoient les résultats aux clients. Par conséquent, Node.js utilise un modèle monothread pour gérer cette situation. Au lieu d'attribuer un thread à chaque requête entrante, il utilise un thread principal pour gérer toutes les requêtes, puis traite les opérations d'E/S de manière asynchrone, évitant ainsi la surcharge et la complexité liées à la création, à la destruction de threads et au basculement entre les threads.

Boucle d'événement

Node.js maintient une file d'attente d'événements dans le thread principal. Lorsqu'une demande est reçue, elle est ajoutée à cette file d'attente en tant qu'événement, puis elle continue de recevoir d'autres demandes. Lorsque le thread principal est inactif (aucune demande n'est entrante), il commence à parcourir la file d'attente des événements pour vérifier s'il y a des événements à traiter. Il existe deux cas : pour les tâches non-E/S, le thread principal les gérera directement et reviendra à la couche supérieure via une fonction de rappel ; pour les tâches d'E/S, il faudra un thread du pool de threads pour gérer l'événement, spécifier une fonction de rappel, puis continuer à parcourir les autres événements de la file d'attente.

Une fois la tâche d'E/S dans le thread terminée, la fonction de rappel spécifiée est exécutée et l'événement terminé est placé à la fin de la file d'attente des événements, en attendant la boucle d'événements. Lorsque le thread principal boucle à nouveau sur cet événement, il le traite directement et le renvoie à la couche supérieure. Ce processus est appelé Event Loop, et son principe de fonctionnement est illustré dans la figure ci-dessous :

Cette figure montre le principe de fonctionnement global de Node.js. De gauche à droite et de haut en bas, Node.js est divisé en quatre couches : la couche application, la couche moteur V8, la couche API Node et la couche LIBUV.

• Couche Application : C'est la couche d'interaction JavaScript. Des exemples courants sont les modules Node.js comme http et fs.
• Couche moteur V8 : il utilise le moteur V8 pour analyser la syntaxe JavaScript, puis interagit avec les API de la couche inférieure.
• Couche API de nœud : elle fournit des appels système pour les modules de couche supérieure, généralement implémentés en C, et interagit avec le système d'exploitation.
• Couche LIBUV : il s'agit d'une encapsulation sous-jacente multiplateforme qui réalise des boucles d'événements, des opérations sur les fichiers, etc., et constitue le cœur de Node.js pour réaliser l'asynchronie.

Que ce soit sur la plate-forme Linux ou sur la plate-forme Windows, Node.js utilise en interne le pool de threads pour effectuer des opérations d'E/S asynchrones, et LIBUV unifie les appels pour les différentes différences de plate-forme. Ainsi, le thread unique dans Node.js signifie uniquement que JavaScript s'exécute dans un seul thread, et non que Node.js dans son ensemble est monothread.

Principe de fonctionnement

Le cœur de l'asynchronie de Node.js réside dans les événements. Autrement dit, il traite chaque tâche comme un événement, puis simule l'effet asynchrone via la boucle d'événements. Pour comprendre et accepter ce fait plus concrètement et plus clairement, nous utilisons le pseudocode pour décrire son principe de fonctionnement ci-dessous.

1. Définir la file d'attente des événements

Puisqu'il s'agit d'une file d'attente, il s'agit d'une structure de données premier entré, premier sorti (FIFO). Nous utilisons un tableau JS pour le décrire comme suit :

/**
 * Define the event queue
 * Enqueue: push()
 * Dequeue: shift()
 * Empty queue: length === 0
 */
let globalEventQueue = [];

Nous utilisons le tableau pour simuler la structure de la file d'attente : le premier élément du tableau est la tête de la file d'attente et le dernier élément est la queue. push() insère un élément à la fin de la file d'attente et shift() supprime un élément en tête de la file d'attente. Ainsi, une simple file d'attente d'événements est réalisée.

2. Définir l'entrée de réception des demandes

Chaque demande sera interceptée et entrera dans la fonction de traitement, comme indiqué ci-dessous :

/**
 * Receive user requests
 * Every request will enter this function
 * Pass parameters request and response
 */
function processHttpRequest(request, response) {
    // Define an event object
    let event = createEvent({
        params: request.params, // Pass request parameters
        result: null, // Store request results
        callback: function() {} // Specify a callback function
    });

    // Add the event to the end of the queue
    globalEventQueue.push(event);
}

Cette fonction regroupe simplement la demande de l'utilisateur sous forme d'événement et la met dans la file d'attente, puis continue de recevoir d'autres demandes.

3. Définir la boucle d'événement

Lorsque le thread principal est inactif, il commence à parcourir la file d'attente des événements. Nous devons donc définir une fonction pour parcourir la file d'attente des événements :

/**
 * The main body of the event loop, executed by the main thread when appropriate
 * Loop through the event queue
 * Handle non-IO tasks
 * Handle IO tasks
 * Execute callbacks and return to the upper layer
 */
function eventLoop() {
    // If the queue is not empty, continue to loop
    while (this.globalEventQueue.length > 0) {
        // Take an event from the head of the queue
        let event = this.globalEventQueue.shift();

        // If it's a time-consuming task
        if (isIOTask(event)) {
            // Take a thread from the thread pool
            let thread = getThreadFromThreadPool();
            // Hand it over to the thread to handle
            thread.handleIOTask(event);
        } else {
            // After handling non-time-consuming tasks, directly return the result
            let result = handleEvent(event);
            // Finally, return to V8 through the callback function, and then V8 returns to the application
            event.callback.call(null, result);
        }
    }
}

Le thread principal surveille en permanence la file d'attente des événements. Pour les tâches d'E/S, il les transmet au pool de threads pour qu'il les gère, et pour les tâches non-E/S, il les gère lui-même et renvoie.

4. Gérer les tâches d'E/S

Une fois que le pool de threads a reçu la tâche, il traite directement l'opération d'E/S, comme la lecture de la base de données :

/**
 * Define the event queue
 * Enqueue: push()
 * Dequeue: shift()
 * Empty queue: length === 0
 */
let globalEventQueue = [];

Lorsque la tâche d'E/S est terminée, le rappel est exécuté, le résultat de la requête est stocké dans l'événement et l'événement est remis dans la file d'attente, en attente de la boucle. Enfin, le fil de discussion actuel est libéré. Lorsque le thread principal boucle à nouveau sur cet événement, il le traite directement.

En résumant le processus ci-dessus, nous constatons que Node.js n'utilise qu'un seul thread principal pour recevoir les requêtes. Après avoir reçu des demandes, il ne les traite pas directement mais les place dans la file d'attente des événements, puis continue de recevoir d'autres demandes. Lorsqu'il est inactif, il traite ces événements via la boucle d'événements, obtenant ainsi un effet asynchrone. Bien sûr, pour les tâches d'E/S, la gestion doit toujours s'appuyer sur le pool de threads au niveau du système.

Par conséquent, nous pouvons simplement comprendre que Node.js lui-même est une plate-forme multithread, mais qu'il traite les tâches au niveau JavaScript dans un seul thread.

Les tâches gourmandes en CPU sont une lacune

À présent, nous devrions avoir une compréhension simple et claire du modèle monothread de Node.js. Il atteint une concurrence élevée et des E/S asynchrones grâce au modèle basé sur les événements. Cependant, il y a aussi des choses pour lesquelles Node.js n'est pas bon.

Comme mentionné ci-dessus, pour les tâches d'E/S, Node.js les transmet au pool de threads pour un traitement asynchrone, ce qui est efficace et simple. Ainsi, Node.js est adapté à la gestion des tâches gourmandes en E/S. Mais toutes les tâches ne sont pas gourmandes en E/S. Lorsque vous rencontrez des tâches gourmandes en ressources CPU, c'est-à-dire des opérations qui reposent uniquement sur des calculs CPU, telles que le cryptage et le déchiffrement des données (node.bcrypt.js), la compression et la décompression des données (node-tar), Node.js les gérera une par une. un. Si la tâche précédente n'est pas terminée, les tâches suivantes ne peuvent qu'attendre. Comme le montre la figure ci-dessous :

Dans la file d'attente des événements, si les tâches de calcul du processeur précédentes ne sont pas terminées, les tâches suivantes seront bloquées, ce qui entraînera une réponse lente. Si le système d'exploitation est monocœur, cela peut être tolérable. Mais désormais, la plupart des serveurs sont multi-CPU ou multicœurs, et Node.js n'a qu'un seul EventLoop, ce qui signifie qu'il n'occupe qu'un seul cœur de processeur. Lorsque Node.js est occupé par des tâches gourmandes en CPU, entraînant le blocage d'autres tâches, il reste encore des cœurs de CPU inactifs, ce qui entraîne un gaspillage de ressources.

Node.js n'est donc pas adapté aux tâches gourmandes en CPU.

Scénarios d'application

• API RESTful : les requêtes et les réponses ne nécessitent qu'une petite quantité de texte et ne nécessitent pas beaucoup de traitement logique. Par conséquent, des dizaines de milliers de connexions peuvent être traitées simultanément.
• Service de chat : il est léger, a un trafic élevé et n'a pas de logique de calcul complexe.

Leapcell : la plate-forme sans serveur de nouvelle génération pour l'hébergement Web, les tâches asynchrones et Redis

Enfin, permettez-moi de vous présenter la plateforme la plus adaptée au déploiement des services Node.js : Leapcell.

1. Prise en charge multilingue

• Développer avec JavaScript, Python, Go ou Rust.

2. Déployez gratuitement un nombre illimité de projets

• Payez uniquement pour l'utilisation – pas de demandes, pas de frais.

3. Rentabilité imbattable

• Payez à l'utilisation sans frais d'inactivité.
• Exemple : 25 $ prend en charge 6,94 millions de requêtes avec un temps de réponse moyen de 60 ms.

4. Expérience de développeur rationalisée

• Interface utilisateur intuitive pour une configuration sans effort.
• Pipelines CI/CD entièrement automatisés et intégration GitOps.
• Mesures et journalisation en temps réel pour des informations exploitables.

5. Évolutivité sans effort et hautes performances

• Mise à l'échelle automatique pour gérer facilement une concurrence élevée.
• Zéro frais opérationnels – concentrez-vous uniquement sur la construction.

Explorez-en davantage dans la documentation !

Twitter de Leapcell : https://x.com/LeapcellHQ

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!