我了解Node如何使用操作系统的多路分解器异步进行非阻塞调用，并通过避免创建数百万个线程（每个客户端一个）来节省大量内存成本，从而在一个线程中处理所有请求。在应用程序中实现并发要简单得多。到目前为止，一切都很好。
当线程池出现时，麻烦就开始了。在节点文档中给出的问题是，只要操作系统的多路分解器支持不好，那么节点就会使用线程池（除了线程，默认为4，默认为128个线程）来实现类似的功能。它还提到文件操作使用线程池而不是OS的多路分解器。
因此，我要说的是，我正在编写一个Web服务器，它需要为每个客户端完成少量文件操作，然后如果一次有数百万个客户端在使用我的应用程序，则Node的4个工作线程可能永远需要作为Node的服务于所有请求默认情况下，线程池目前可以处理四个文件操作。其他人则必须等到这些线程空闲为止。即使考虑到Node线程池的最佳情况，考虑到Tomcat可以在阻塞模式下并行处理数百万个文件操作的情况下，128个线程可能也不是更好的选择。
这让我开始思考Web服务器是否有太多的IO操作（主要是文件和数据库相关的），Node真的是正确的选择吗？
答案 0 :(得分：0)
据我所知，Node.js的主要思想之一是，您应该设计服务器应用程序，以便将持久性可变状态数据的存储或检索尽快推迟到其他系统。
如果这样做，则可以在同一台计算机或不同计算机上群集多个节点进程实例，每个实例都在运行您的代码。
因此，无论采用哪种技术，都可以获得比单个整体过程更大的可扩展性。
这个概念就是给Node.js命名的原因。每个进程都应该是某个群集中的一个节点。
我不了解您自己，但是我不想重新实现并将企业数据存储解决方案的功能混合到我的业务逻辑中，因为有些开发人员只关注所涉及的问题及其可能性，大多数应用程序开发人员都可以做得很好。
您是否实际测试过是否存在性能问题？如果没有，您怎么知道根本没有问题？大多数文件可能只打开了很短的时间。
在技术层面上，Node.js可以同时打开的文件数量受到限制。达到该级别后，文件操作将失败，并显示EMFILE错误（打开的文件过多）。要超出此数量，您可以使用https://github.com/isaacs/node-graceful-fs的Node.js模块来进行进一步的文件操作。