Une brève analyse des principes de haute concurrence dans Node

Regardons d'abord quelques déclarations courantes

• nodejs est un modèle d'E/S monothread + non bloquant
• nodejs convient à une concurrence élevée
• nodejs convient aux applications à forte intensité d'E/S, pas d'applications gourmandes en CPU [Recommandations de didacticiel associées : Tutoriel vidéo Nodejs]

Avant d'analyser en détail si ces déclarations sont vraies et pourquoi, faisons un travail préparatoire

Commençons par le début

Un courant l'application Web fera Quelles choses

• Opérations (exécution de la logique métier, opérations mathématiques, appels de fonction, etc. Le travail principal est effectué sur le processeur)
• E/S (telles que la lecture et l'écriture de fichiers, la lecture et l'écriture de bases de données , lecture et écriture de requêtes réseau, etc. Le travail principal est effectué sur divers périphériques d'E/S, tels que des disques, des cartes réseau, etc.)

Une implémentation typique d'une application Web traditionnelle

• Plusieurs processus , une requête crée un processus (enfant) + bloque les E/S (c'est-à-dire bloque les E/S ou BIO)
• Multi-threading, une requête crée un thread + bloque les E/S

---

Pseudo d'exemple d'application Web multi-processus code

listenFd = new Socket(); // 创建监听socket
Bind(listenFd, 80); // 绑定端口
Listen(listenFd);   // 开始监听

for ( ; ; ) {
    // 接收客户端请求，通过新的socket建立连接
    connFd = Accept(listenFd);
    // fork子进程
    if ((pid = Fork()) === 0) {
        // 子进程中
        // BIO读取网络请求数据，阻塞，发生进程调度
        request = connFd.read();
        // BIO读取本地文件，阻塞，发生进程调度
        content = ReadFile('test.txt');
        // 将文件内容写入响应
        Response.write(content);
    }
}

L'application multithread est en fait similaire au multi-processus, sauf qu'une requête est allouée à un processus. Devient une demande d'allocation d'un thread. Les threads sont plus légers que les processus et occupent moins de ressources système (ps : ce qu'on appelle le changement de contexte, une petite explication : un processeur monocœur ne peut exécuter des tâches que dans un processus ou un thread en même temps, mais pour le plaisir. Le parallélisme des macros sur Internet nécessite de basculer entre plusieurs processus ou threads en fonction des tranches de temps pour garantir que chaque processus et thread a une chance d'être exécuté.) La surcharge est également plus petite en même temps, il est plus facile de le faire ; partager la mémoire entre les threads, ce qui facilite le développement

Up L'article mentionnait deux points essentiels des applications Web, l'un est le modèle de thread et l'autre est le modèle d'E/S. Alors, qu’est-ce qui bloque exactement les E/S ? Quels autres modèles d'E/S existe-t-il ? Ne vous inquiétez pas, voyons d'abord ce qu'est une obstruction

Qu'est-ce qu'une obstruction ? Qu’est-ce qui bloque les E/S ?

En bref, le blocage signifie qu'avant le retour de l'appel de fonction, le processus (thread) actuel sera suspendu et entrera dans l'état d'attente. Dans cet état, le processus (thread) actuel se mettra en pause et entraînera le traitement (thread) du processeur. ) planification des threads. La fonction ne reviendra à l'appelant qu'une fois tous les travaux internes terminés. Ainsi, le blocage des E/S signifie qu'après que l'application a appelé l'opération d'E/S via l'API, le thread (thread) actuel entrera dans l'état d'attente et le code ne peut pas continuer.Poursuivre l'exécution.À ce stade, le processeur peut effectuer une planification de thread (thread), c'est-à-dire passer à d'autres threads exécutables (threads) pour continuer l'exécution. Le thread (thread) actuel reviendra après la demande d'E/S sous-jacente. est traité. Vous pouvez continuer à exécuter

Plusieurs threads + Quel est le problème avec le modèle d'E/S bloquant ?

Après avoir compris ce que sont le blocage et le blocage des E/S, analysons les inconvénients du modèle multi-processus (thread) + blocage des E/S des applications Web traditionnelles.

Étant donné qu'une requête doit se voir attribuer un thread entrant (thread), un tel système doit maintenir un grand nombre de threads entrants (thread) lorsque le degré de concurrence est important et nécessite un grand nombre de changements de contexte, ce qui nécessite une grande quantité de CPU, de mémoire et d'autres ressources système, donc lorsque des demandes simultanées élevées arrivent, la surcharge du CPU et de la mémoire augmentera fortement, ce qui peut rapidement faire tomber l'ensemble du système et rendre le service indisponible

nodejs. implémentation de l'application

Voyons ensuite comment les applications nodejs sont implémentées.

Evénementiel, monothread (thread principal)

• E/S non bloquantes Comme vous pouvez le voir sur le site officiel, les deux principales fonctionnalités de nodejs sont un modèle d'E/S monothread piloté par les événements et "non bloquant". Les étudiants front-end doivent être familiers avec les mécanismes de thread unique et de boucle d'événement de js, étudions donc principalement en quoi consiste cette "E/S non bloquante". Tout d'abord, examinons un code commun pour les applications serveur nodejs

• const net = require('net');
  const server = net.createServer();
  const fs = require('fs');
  
  server.listen(80);  // 监听端口
  // 监听事件建立连接
  server.on('connection', (socket) => {
      // 监听事件读取请求数据
      socket.on('data', (data) => {
      // 异步读取本地文件
      fs.readFile('test.txt', (err, data) => {
              // 将读取的内容写入响应
              socket.write(data);
              socket.end();
          })
      });
  });

Vous pouvez voir que dans nodejs, nous pouvons effectuer des opérations d'E/S de manière asynchrone. Après avoir appelé l'opération d'E/S via l'API, elle reviendra. immédiatement, puis vous pouvez continuer à exécuter une autre logique de code, alors pourquoi les E/S dans nodejs sont-elles « non bloquantes » ? Avant de répondre à cette question, faisons un peu de travail de préparation. Veuillez vous référer à l'explication vidéo avancée de nodejs :

Entrer dans l'apprentissage

Étapes de base de l'opération de lecture

Tout d'abord, examinons les étapes requises pour la prochaine opération de lecture

.

• 用户程序调用I/O操作API，内部发出系统调用，进程从用户态转到内核态
• 系统发出I/O请求，等待数据准备好（如网络I/O，等待数据从网络中到达socket；等待系统从磁盘上读取数据等）
• 数据准备好后，复制到内核缓冲区
• 从内核空间复制到用户空间，用户程序拿到数据

接下来我们看一下操作系统中有哪些I/O模型

几种I/O模型

阻塞式I/O

---

非阻塞式I/O

---

I/O多路复用（进程可同时监听多个I/O设备就绪）

---

信号驱动I/O

---

异步I/O

---

那么nodejs里到底使用了哪种I/O模型呢？是上图中的“非阻塞I/O”吗？别着急，先接着往下看，我们来了解下nodejs的体系结构

nodejs体系结构，线程、I/O模型分析

最上面一层是就是我们编写nodejs应用代码时可以使用的API库，下面一层则是用来打通nodejs和它所依赖的底层库的一个中间层，比如实现让js代码可以调用底层的c代码库。来到最下面一层，可以看到前端同学熟悉的V8，还有其他一些底层依赖。注意，这里有一个叫libuv的库，它是干什么的呢？从图中也能看出，libuv帮助nodejs实现了底层的线程池、异步I/O等功能。libuv实际上是一个跨平台的c语言库，它在windows、linux等不同平台下会调用不同的实现。我这里主要分析linux下libuv的实现，因为我们的应用大部分时候还是运行在linux环境下的，且平台间的差异性并不会影响我们对nodejs原理的分析和理解。好了，对于nodejs在linux下的I/O模型来说，libuv实际上提供了两种不同场景下的不同实现，处理网络I/O主要由epoll函数实现（其实就是I/O多路复用，在前面的图中使用的是select函数来实现I/O多路复用，而epoll可以理解为select函数的升级版，这个暂时不做具体分析），而处理文件I/O则由多线程（线程池） + 阻塞I/O模拟异步I/O实现

---

下面是一段我写的nodejs底层实现的伪代码帮助大家理解

listenFd = new Socket();    // 创建监听socket
Bind(listenFd, 80); // 绑定端口
Listen(listenFd);   // 开始监听

for ( ; ; ) {
    // 阻塞在epoll函数上，等待网络数据准备好
    // epoll可同时监听listenFd以及多个客户端连接上是否有数据准备就绪
    // clients表示当前所有客户端连接，curFd表示epoll函数最终拿到的一个就绪的连接
    curFd = Epoll(listenFd, clients);

    if (curFd === listenFd) {
        // 监听套接字收到新的客户端连接，创建套接字
        int connFd = Accept(listenFd);
        // 将新建的连接添加到epoll监听的list
        clients.push(connFd);
    }

    else {
        // 某个客户端连接数据就绪，读取请求数据
        request = curFd.read();
        // 这里拿到请求数据后可以发出data事件进入nodejs的事件循环
        ...
    }
}

// 读取本地文件时，libuv用多线程（线程池） + BIO模拟异步I/O
ThreadPool.run((callback) => {
    // 在线程里用BIO读取文件
    String content = Read('text.txt');  
    // 发出事件调用nodejs提供的callback
});

通过I/O多路复用 + 多线程模拟的异步I/O配合事件循环机制，nodejs就实现了单线程处理并发请求并且不会阻塞。所以回到之前所说的“非阻塞I/O”模型，实际上nodejs并没有直接使用通常定义上的非阻塞I/O模型，而是I/O多路复用模型 + 多线程BIO。我认为“非阻塞I/O”其实更多是对nodejs编程人员来说的一种描述，从编码方式和代码执行顺序上来讲，nodejs的I/O调用的确是“非阻塞”的

总结

至此我们应该可以了解到，nodejs的I/O模型其实主要是由I/O多路复用和多线程下的阻塞I/O两种方式一起组成的，而应对高并发请求时发挥作用的主要就是I/O多路复用。好了，那最后我们来总结一下nodejs线程模型和I/O模型对比传统web应用多进（线）程 + 阻塞I/O模型的优势和劣势

• nodejs utilise un modèle à thread unique pour économiser les coûts de maintenance du système et de commutation de plusieurs threads. Dans le même temps, le modèle d'E/S multiplexées peut empêcher le thread unique de nodejs de se bloquer sur une certaine connexion. Dans les scénarios à forte concurrence, les applications nodejs doivent uniquement créer et gérer des descripteurs de socket correspondant à plusieurs connexions client sans créer de processus ou de threads correspondants. La surcharge du système est considérablement réduite, elle peut donc gérer plus de connexions client en même temps
• Nodejs ne le peut pas. améliorer l'efficacité des opérations d'E/S réelles sous-jacentes. Si les E/S sous-jacentes deviennent le goulot d'étranglement des performances du système, nodejs ne peut toujours pas le résoudre, c'est-à-dire que nodejs peut recevoir un nombre élevé de requêtes simultanées, mais s'il doit gérer un grand nombre d'opérations d'E/S lentes (telles que la lecture et la lecture). l'écriture de disques), cela peut toujours entraîner une surcharge des ressources système. Par conséquent, une simultanéité élevée ne peut pas être simplement résolue par un modèle d'E/S monothread + non bloquant.
• Les applications gourmandes en CPU peuvent faire du modèle monothread de nodejs un goulot d'étranglement en termes de performances.
• nodejs est adapté au traitement à haute simultanéité. d'une petite quantité de logique métier ou d'E/S rapides (comme la lecture et l'écriture de mémoire)

Pour plus de connaissances sur les nœuds, veuillez visiter : tutoriel Nodejs !

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!