单线程 Node.js 如何并发处理请求？

Question

我目前正在深入学习Nodejs平台。众所周知，Nodejs 是单线程的，如果它执行阻塞操作（例如 fs.readFileSync），线程应该等待完成该操作。我决定做一个实验：我创建了一个服务器，它在每次请求时都会从文件中获取大量数据

const { createServer } = require('http');
const fs = require('fs');

const server = createServer();

server.on('request', (req, res) => {
    let data;
    data =fs.readFileSync('./big.file');
    res.end(data);
});

server.listen(8000);

另外，我启动了 5 个终端以向服务器发出并行请求。我等着看，在处理一个请求时，其他请求应该等待从第一个请求完成阻塞操作。但是，其他 4 个请求同时响应。为什么会出现这种行为？

Answer 1

您可能会看到res.end() 内部实现的一些异步部分来实际发送大量数据，或者您看到所有数据都非常快速且连续地发送，但客户端不能处理它的速度足够快以实际连续显示它，并且因为客户端每个都在他们自己的单独进程中，它们“似乎”显示它同时到达只是因为它们反应太慢而无法显示实际到达顺序。

必须使用网络嗅探器来查看其中哪些实际发生或运行一些不同的测试或在res.end() 的实现中放置一些日志记录，或在客户端的 TCP 堆栈中挖掘一些日志记录以确定实际顺序不同请求之间的数据包到达率。

---

如果您有一台服务器并且它有一个请求处理程序正在执行同步 I/O，那么您将不会同时获得多个请求处理。如果您认为这种情况正在发生，那么您将必须准确记录您是如何衡量或得出结论的（这样我们可以帮助您消除误解），因为这不是 node.js 在使用阻塞、同步 I/O 等时的工作方式作为fs.readFileSync()。

node.js 将您的 JS 作为单线程运行，当您使用阻塞、同步 I/O 时，它会阻塞 Javascript 的一个单线程。这就是为什么您永远不应该在服务器中使用同步 I/O，除非在启动期间只运行一次的启动代码中。

很明显，fs.readFileSync('./big.file') 是同步的，因此在第一个 fs.readFileSync() 完成之前，您的第二个请求不会开始处理。而且，在同一个文件上一遍又一遍地调用它会非常快（操作系统磁盘缓存）。

但是，res.end(data) 是非阻塞、异步的。 res 是一个流，您正在为流提供一些数据来处理。它会通过套接字发送尽可能多的内容，但如果它由 TCP 控制流量，它将暂停，直到套接字上有更多空间可以发送。发生多少取决于您的计算机、计算机的配置以及到客户端的网络链接。

所以，可能会发生以下事件序列：

1. 第一个请求到达并执行fs.readFileSync() 并调用res.end(data)。这开始向客户端发送数据，但由于 TCP 流控制，它在完成之前返回。这会将 node.js 发送回其事件循环。

2. 第二个请求到达并执行fs.readFileSync() 并调用res.end(data)。这开始向客户端发送数据，但由于 TCP 流控制，它在完成之前返回。这会将 node.js 发送回其事件循环。

1234563如果它确实为这些事件提供服务，它可以（从客户端的角度）呈现不同请求的真正并发性）。

此外，客户端可能会导致它显示为已排序。每个客户端都在读取不同的缓冲套接字，如果它们都在不同的终端中，那么它们是多任务的。因此，如果每个客户端的套接字上的数据多于它可以立即读取和显示的数据（可能就是这种情况），那么每个客户端将读取一些、显示一些、读取更多、显示更多等等......如果在您的服务器上发送每个客户端的响应之间的延迟小于在客户端上读取和显示的延迟，那么客户端（每个客户端都在自己的单独进程中）能够同时运行。

---

当您使用异步 I/O（例如 fs.readFile()）时，正确编写的 node.js Javascript 代码可以同时“进行”许多请求。它们实际上并不会在完全相同的时间同时运行，但可以运行，做一些工作，启动异步操作，然后让位于让另一个请求运行。使用正确编写的异步 I/O，可以从外部世界看到并发处理，即使它更类似于在请求处理程序等待异步 I/O 请求完成时共享单个线程。但是，您展示的服务器代码不是这种协作的异步 I/O。

Answer 2

也许与您的问题没有直接关系，但我认为这很有用，

您可以使用流而不是将整个文件读入内存，例如：

const { createServer } = require('http');
const fs = require('fs');

const server = createServer();

server.on('request', (req, res) => {
   const readStream = fs.createReadStream('./big.file'); // Here we create the stream.
   readStream.pipe(res); // Here we pipe the readable stream to the res writeable stream.
});

server.listen(8000);

这样做的重点是：

• 看起来更好。
• 您没有将完整文件存储在 RAM 中。

这样会更好，因为它是非阻塞的，并且res 对象已经是一个流，这意味着数据将以块的形式传输。

好吧streams = chunked

为什么不从文件中读取块并实时发送它们，而不是读取一个非常大的文件并在之后将其分成块？

为什么在真正的生产服务器上真的很重要？

因为每次收到请求时，您的代码都会将该大文件添加到 ram 中，因此添加是并发的，因此您希望同时提供多个文件，所以让我们做最高级的数学吧糟糕的教育允许：

1 个 1gb 文件的请求 = 1gb in ram

2 个 1gb 文件的请求 = 2gb in ram

等

这显然不能很好地扩展，对吧？

Streams 允许将该数据与函数的当前状态（在该范围内）解耦，因此简单来说，它将是（默认 chunk 大小为 16kb）：

1 个 1gb 文件的请求 = 16kb in ram

2 次请求 1gb 文件 = 32kb in ram

等

而且，操作系统已经将流传递给节点 (fs)，因此它可以端到端地处理流。

希望对您有所帮助：D。

PD：永远不要在异步操作（非阻塞）中使用同步操作（阻塞）。