fs.createRead/WriteStream()与fs.promises.open()

Question

哪一个更适合于在节点服务器应用程序的文件管理器类型中处理文件读/写操作？

一个比另一个快吗？速度非常重要，因为应用程序应该能够同时处理许多用户请求

Answer 1

以下哪一项更适合处理文件管理器类型的节点服务器应用程序中的文件读/写操作？

两者都可用于节点服务器应用程序。然而，在节点的HTTP实现中，request和response都是基于流的，这意味着基于流的方法在处理大型I/O操作方面更加灵活。

是一个比另一个快？速度非常重要，因为应用程序应该能够同时处理许多用户请求。

有强有力的证据表明，stream在内存使用和时间方面都更好。我将借用Node.js Design Patterns - Second Edition: Master best practices to build modular and scalable server-side web applications Chapter 5 - Coding with Streams中的一些示例

缓冲区方法：

const fs = require('fs');
const zlib = require('zlib');

const file = process.argv[2];

fs.readFile(file, (err, buffer) => {
  zlib.gzip(buffer, (err, buffer) => {
    fs.writeFile(file + '.gz', buffer, err => {
      console.log('File successfully compressed');
    });
  });
});

结果将是正常的，但当尝试处理大小超过1 1GB的文件时。我们会遇到这个错误。

RangeError: File size is greater than possible Buffer: 0x3FFFFFFF bytes

使用与stream方法相同的文件：

const fs = require('fs');
const zlib = require('zlib');
const file = process.argv[2];

fs.createReadStream(file)
  .pipe(zlib.createGzip())
  .pipe(fs.createWriteStream(file + '.gz'))
  .on('finish', () => console.log('File successfully compressed'));

想象一下，如果一个节点进程必须处理100个请求的并发，每个请求都试图上传高达100MB的文件大小。这个node.js进程只会将文件二进制文件的所有缓冲区保存在内存中，而您的服务器只会遭受内存泄漏。

在时间效率上，stream有助于以块为单位处理数据，因此它明显地提高了速度

​

​

免责声明:大多数示例和图片来自Node.js Design Patterns - Second Edition - Chapter 5，我没有任何这些材料，这只是为了教育目的。

Answer 2

streams的独特之处在于，与传统方式不同，streams不是像传统方式那样一次性将文件读入内存，而是逐段读取数据块，处理其内容，而不是将其全部保存在内存中。

这使得streams在处理大量数据时变得非常强大，例如，文件大小可能大于可用内存空间，从而无法将整个文件读取到内存中进行处理。这就是救命稻草的地方！

使用streams处理较小的数据块，使得读取较大的文件成为可能。

与其他数据处理方法相比，Streams基本上提供了两个主要优势：

1. 内存效率:您无需在内存中加载大量数据即可进行处理
2. time efficiency:一有数据就立即开始处理所需的时间大大缩短，而不必等到整个有效负载传输完毕后再进行处理

Answer 3

fs和fs.promises模块同样适用。

这两个模块都提供了具有同步和异步形式的操作。

它们只是在处理这些操作的完成方式上有所不同。fs使用回调来实现这一点，而fs.promises显然使用了promises。

归根结底就是编程风格。首先，promises可以帮助您避免经典的callback hell。