Node における高い同時実行性の原理の簡単な分析

最初にいくつかの一般的なステートメントを見てみましょう

• nodejs はシングルスレッドのノンブロッキング I/O モデルです
• nodejs は高い同時実行性に適しています
• nodejs は I/O 集中型のアプリケーションには適していますが、CPU 集中型のアプリケーションには適していません [関連チュートリアルの推奨事項: nodejs ビデオ チュートリアル ]

これらを詳しく分析してみましょう。「はい」とその理由を言う前に、いくつかの準備作業をしてみましょう

最初から始めましょう

一般的な Web アプリケーションは何を行うのかdo

• 操作 (ビジネス ロジック、数学的演算、関数呼び出しなどを実行します。主な作業は CPU で実行されます)
• I/O (読み取りやファイルの書き込み、データベースの読み取りと書き込み、ネットワーク リクエストの読み取りと書き込みなど。主にディスクやネットワーク カードなどのさまざまな I/O デバイスで動作します。)

典型的な従来型Web アプリケーションの実装

• マルチプロセス、1 つのリクエストが I/O をブロックする (子) プロセスをフォークします (つまり、I/O または BIO をブロックします)
#Multi-スレッド化すると、1 つのリクエストが I/O をブロックするスレッドを作成します

---

マルチプロセス Web アプリケーションの例の疑似コード

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);
    }
}

マルチスレッド アプリケーションは、実際にはマルチプロセスに似ています。ただし、1 つのリクエストが 1 つのスレッドに割り当てられるのではなく、1 つのリクエストが 1 つのプロセスに割り当てられる点が異なります。スレッドはプロセスよりも軽く、占有するシステム リソースも少なくなります。コンテキスト スイッチング (ps: いわゆるコンテキスト スイッチング、少し説明: シングルコア CPU は同時に 1 つのプロセスまたはスレッドでしかタスクを実行できませんが、インターネット上のマクロの並列処理では、各プロセスやスレッドが実行される機会を確保するために、タイム スライスに従って複数のプロセスやスレッド間を行き来する必要があります。) オーバーヘッドも小さくなり、同時に、スレッド間でメモリを共有することで開発が容易になります

Web アプリケーションの 2 つの核心ポイントは上で述べました。1 つはスレッド (スレッド) モデル、もう 1 つは I/O モデルです。では、I/O をブロックするとは具体的に何でしょうか?他にどのような I/O モデルがありますか?心配しないでください。まず、何がブロックされているかを見てみましょう。

ブロックとは何ですか?ブロッキング I/O とは何ですか?

つまり、ブロッキングとは、関数呼び出しが戻る前に、現在の (スレッド) スレッドが一時停止され、待機状態になることを意味します。この状態では、現在の (スレッド) スレッドは一時停止します。 CPU の受信 (スレッド) プロセスのスケジューリングを引き起こします。この関数は、すべての内部作業が完了した後にのみ呼び出し元に戻ります。

したがって、I/O をブロックするということは、アプリケーションが API を通じて I/O 操作を呼び出した後、現在のスレッド (スレッド) が待機状態にある場合、コードは実行を続行できません。このとき、CPU はスレッド (スレッド) スケジューリングを実行できます。つまり、他の実行可能なスレッドに切り替えて実行を継続します。現在のスレッド (スレッド) が基礎となる I/O の処理を​​完了した後、 O request その場合のみ、戻って実行を継続します

マルチスレッド (スレッド) ブロッキング I/O モデルの何が問題になっていますか?

ブロッキングとブロッキング I/O とは何かを理解した後、従来の Web アプリケーションのマルチスレッド (スレッド) ブロッキング I/O モデルの欠点を分析しましょう。

リクエストにはスレッド(スレッド)を割り当てる必要があるため、同時実行量が多く、多数のコンテキストスイッチが必要な場合、このようなシステムでは多数のスレッド(スレッド)を維持する必要があります。大量の CPU、メモリ サポートなどのシステム リソースが必要となるため、同時リクエストが大量に発生すると、CPU とメモリのオーバーヘッドが急激に増加し、システム全体がすぐにダウンしてサービスが利用できなくなる可能性があります

nodejs アプリケーションの実装

次に、nodejs アプリケーションがどのように実装されるかを見てみましょう。

イベント駆動型、シングルスレッド (メインスレッド)
• ノンブロッキング I/O 公式 Web サイトにあるように、nodejs の 2 つの主な機能は、シングルスレッドのイベント駆動型と「ノンブロッキング」I/O モデルです。シングルスレッドのイベント駆動の方が理解しやすいです。フロントエンドの学生は js のシングルスレッドとイベント ループの仕組みをよく知っているはずなので、主にこの「ノンブロッキング I/O」が何であるかを学習しましょう。まず、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();
        })
    });
});

nodejs では、I/O 操作を非同期で実行できることがわかります。 API を介した操作 すぐに返され、その後は他のコード ロジックの実行を続けることができます。この質問に答える前に、いくつかの準備作業をしましょう。nodejs の高度なビデオ説明を参照してください:

Enter learning

操作の基本手順を読む

最初に確認してください。次の読み取り操作で実行する必要がある手順は何ですか

• 用户程序调用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 はシングルスレッド モデルを使用して、システムのメンテナンスと複数のスレッドの切り替えのコストを節約します。同時に、多重化 I/O モデルにより、nodejs のシングルスレッドが特定の接続をブロックするのを防ぐことができます。 。 優れた。同時実行性の高いシナリオでは、nodejs アプリケーションは、対応するプロセスやスレッドを作成せずに、複数のクライアント接続に対応するソケット記述子を作成して管理するだけで済みます。システムのオーバーヘッドが大幅に削減されるため、より多くのクライアント接続を同時に処理できます
• Nodejs基礎となる実際の I/O 操作の効率を向上させることはできません。基盤となる I/O がシステムのパフォーマンスのボトルネックになった場合、nodejs は依然としてそれを解決できません。つまり、nodejs は大量の同時リクエストを受信できますが、大量の低速 I/O 操作 (読み取りや読み取りなど) を処理する必要がある場合、ディスクへの書き込みなど）、それでもシステム リソースの過負荷が発生する可能性があります。したがって、高い同時実行性は、シングルスレッドのノンブロッキング I/O モデルだけでは解決できません。
#CPU 集中型のアプリケーションでは、nodejs のシングルスレッド モデルがパフォーマンスのボトルネックになる可能性があります。
• nodejs は、同時実行性の高い処理に適しています。 少量のビジネス ロジックまたは高速 I/O (メモリの読み書きなど)
• #ノード関連の知識の詳細については、次のサイトを参照してください:

nodejs チュートリアル

!

以上がNode における高い同時実行性の原理の簡単な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。