javascript - node.js I/O 非阻塞 - 了解何时最有益

Question

在阅读了事件循环以及异步在 node.js 中的工作原理之后，这是我对 node.js 的理解:

• Node 实际上一次运行一个进程，而不是同时运行。
• 当调用多个数据库 I/O 任务时，Node 真正发挥了作用。它运行得更快(比阻塞 I/O)，因为它在处理下一个调用之前不等待一个调用的响应。在处理另一个调用时，当第一个调用的结果到达时，它“返回”，基本上来回交叉调用和回调，不会让 OS 进程空闲，而不是阻塞 I/O做。如果我错了，请纠正我。

但这是我的问题:仅当处理 Node 发送的请求的实体(服务器/进程/线程？)不是 Node 服务器本身时，非阻塞 I/O 似乎比阻塞 I/O 更快。

如果处理请求的服务器与发出请求的服务器相同，会出现什么情况？如果我的第一个项目符号是正确的，那么在这种情况下，如果阻塞 I/O 使用不同的线程来完成任务，它会比非阻塞 I/O 工作得更快吗？文件压缩是否可以作为在多线程阻塞 I/O 上运行速度更快的 I/O 任务的示例？

Answer 1

非阻塞操作的主要好处是相对重量级的 CPU 线程不会在服务器等待其他地方发生某些事情(网络、磁盘 I/O 等)时保持忙碌。这意味着许多不同的请求可以在只有一个 CPU 线程的情况下“进行中”，并且没有线程卡在等待 I/O。编写异步友好代码和使用异步 I/O 操作的负担又落在了开发人员身上，但在繁重的 I/O 绑定(bind)操作中，服务器可伸缩性确实有好处。单线程模型也确实简化了对共享资源的访问，因为线程冲突、死锁等的机会要少得多……这可以减少难以发现的线程同步错误，这些错误往往只会在最糟糕的时间(例如忙碌的时候)。

是的，只有当处理 I/O 操作的代理不是 node.js 本身时，非阻塞 I/O 才真正有用，因为 Node 中非阻塞 I/O 的全部意义在于 Node 可以自由使用它的单个线程在 I/O 操作运行时去做其他事情，如果它是服务于 I/O 操作的 Node ，那将是不正确的。

抱歉，我不明白你问题中关于文件压缩的​​部分。文件压缩需要一定数量的 CPU，无论谁处理它，如果您试图决定是在 Node 本身内部还是在外部进程(运行不同的线程)中处理它，则有很多不同的考虑因素。这不是一个简单的问题。我可能会从使用我已有的用于压缩的任何代码开始(例如，如果你有，则使用 Node 代码，如果你有，则使用外部库/进程)，并且只有在你实际遇到性能问题时才研究不同的选项或可扩展性问题，或者知道您有问题。

仅供引用，一种处理压缩的简单机制是将未压缩的数据假脱机到 node.js 应用程序的临时目录中的文件，然后有另一个进程(可以在任何系统中编写，甚至包括 Node )只在应用压缩的临时目录中查找文件，然后对生成的压缩数据执行更永久的操作。