Node 如何处理线程池中只有几个线程的密集型文件操作？

Question

我理解了Node是如何使用操作系统的去多路复用器使非阻塞调用异步的，它通过避免创建一百万个线程（每个客户端一个线程）来节省大量的内存成本，从而在单个线程中处理所有请求。它还帮助开发人员在更简单的应用程序中处理并发问题way.All目前为止做得很好。

当线程池进入节点留档时，我的麻烦就开始了picture.its在节点留档中，只要操作系统的多路分解器支持不好，节点就使用线程池（默认为4个线程，最大128个线程）来实现类似的functionality.It还提到文件操作使用线程池而不是操作系统的多路分解器。

因此，我担心的是，假设我正在编写一个web服务器，每个客户端需要完成很少的文件操作，那么如果一百万个客户端同时使用我的应用程序，那么节点的4个工作线程可能永远无法满足所有请求，因为默认情况下，节点的线程池此时可以处理4个文件操作。其他人必须等到这些线程被释放。即使考虑节点线程池128个线程的最佳情况，考虑到Tomcat可以在阻塞模式下并行处理数百万个文件操作，也未必更好。

这让我想到，如果Web服务器有太多的IO操作（主要是文件和数据库相关），Node真的是正确的选择吗？

Answer 1

据我所知，Node.js背后的主要思想之一是，您应该设计服务器应用程序，以便持久、可变状态数据的存储或检索尽可能快地被其他系统击败。

如果您这样做，您就可以将节点进程的多个实例集群在同一台计算机或不同的计算机上，每个实例都运行您的代码。

因此，无论采用何种技术实现，您都可以获得比单一整体流程更高的可伸缩性。

这个概念就是Node.js的名字。每个进程应该是某个集群中的一个节点。

我不知道你自己，但我不想重新实施企业数据存储解决方案并将它的功能混合到我的业务逻辑中，因为有些开发人员只关注相关的问题，而大多数应用程序开发人员不可能做得和他们一样好。

但是，您实际测试过是否存在性能问题吗？如果没有，你怎么知道有问题呢？大多数文件可能只打开一小段时间。

在技术层面上，Node.js可以同时打开的文件数量是有限制的。达到该级别后，文件操作将失败，并出现EMFILE错误(打开的文件太多)。为了超过这个数量，有一个Node.js模块，您可以使用https://github.com/isaacs/node-graceful-fs对进一步的文件操作进行排队。