以下两张图是我对线程在事件驱动的 Web 服务器（如 Node.js + JavaScript）中与非事件驱动的 Web 服务器（如 IIS + C#）相比如何工作的理解
从图中很容易看出，在传统的 Web 服务器上，用于执行 3 个长时间运行的操作的线程数比事件驱动的 Web 服务器上的多（3 比 1。）
我认为我得到了正确的“传统 Web 服务器”计数 (3)，但我想知道事件驱动的 (1)。以下是我的问题：
假设在事件驱动的场景中只使用了一个线程是否正确？这不可能是正确的，必须创建一些东西来处理 I/O 任务。正确的？
事件服务器如何处理 I/O？假设 I/O 是从数据库中读取的。我怀疑网络服务器必须创建一个线程来交出连接到数据库的工作？正确的？
如果事件驱动的 Web 服务器确实创建了线程来处理 I/O，那么收益在哪里？
我的困惑的一个可能解释是，在传统和事件驱动两种情况下，确实创建了三个单独的线程来处理 I/O（图中未显示），但区别实际上在于线程数Web 服务器本身，而不是在 I/O 线程上。那准确吗？
Node 可以使用线程进行 IO。JS 代码运行在单线程中，但所有的 IO 请求都在并行线程中运行。如果您希望某些 JS 代码在并行线程中运行，请使用 thread-a-gogo 或其他一些可以减轻这种行为的包。
与 一样1.，线程由 Node 创建用于 IO 操作。
除非您愿意，否则您不必处理线程。更容易开发。至少这是我的观点。
可以对节点应用程序进行编码，使其像另一个 Web 服务器一样运行。通常，JS 代码在单个线程中运行，但有一些方法可以使其表现不同。
就个人而言，如果你想尝试线程，我推荐threads-a-gogo（包名不是那么暴露，但它很容易使用）。它更快。Node 还支持多个进程，如果您也想尝试一下，可以运行一个完全独立的进程。
描绘 NodeJS 的最佳方式就像一只愤怒的松鼠（即您的线程）在轮子中运行，有无限数量的鸽子（您的 I/O）可用于传递消息。
节点中的 I/O 是“免费的”。你的松鼠负责建立连接并将鸽子送走，然后在鸽子检索数据时继续做其他事情，只在鸽子返回时处理数据。
如果你编写了糟糕的代码，你最终可能会让松鼠等待每只鸽子。
所以总是写非阻塞的 i/o 代码。
如果你能鼓励你的鸽子答应回来；）
Promise 和生成器可能是您可以采取的最佳方法。
但是，您始终可以使用 Node 集群建立一个主松鼠，该松鼠将根据主松鼠可以找到的用于分配工作的 CPU 数量来繁殖子松鼠。
希望这会有所帮助，并注意完全没有汽车类比。