精读《如何利用 Nodejs 监听文件夹》

李涛发布于2019-08-26 11:59 / 3338人阅读

摘要：引言本期精读的文章是，探讨如何监听文件的变化。概述使用使用内置函数似乎可以解决问题但你可能会发现这个回调执行有一定延迟，因为是通过轮询检测文件变化的，它并不能实时作出反馈，而且只能监听一个文件，存在效率问题。

1 引言

本期精读的文章是：How to Watch for Files Changes in Node.js，探讨如何监听文件的变化。

如果想使用现成的库，推荐 chokidar 或 node-watch，如果想了解实现原理，请往下阅读。

2 概述 使用 fs.watchfile

使用 fs 内置函数 watchfile 似乎可以解决问题：

</>复制代码 
fs.watchFile(dir, (curr, prev) => {});

但你可能会发现这个回调执行有一定延迟，因为 watchfile 是通过轮询检测文件变化的，它并不能实时作出反馈，而且只能监听一个文件，存在效率问题。

使用 fs.watch

使用 fs 的另一个内置函数 watch 是更好的选择：

</>复制代码 
fs.watch(dir, (event, filename) => {});

watch 通过操作系统提供的文件更改通知机制，在 Linux 操作系统使用 inotify，在 macOS 系统使用 FSEvents,在 windows 系统使用 ReadDirectoryChangesW，而且可以用来监听目录的变化，在监听文件夹的场景中，比创建 N 个 fs.watchfile 效率高出很多。

</>复制代码 
$ node file-watcher.js
[2018-05-21T00:55:52.588Z] Watching for file changes on ./button-presses.log
[2018-05-21T00:56:00.773Z] button-presses.log file Changed
[2018-05-21T00:56:00.793Z] button-presses.log file Changed
[2018-05-21T00:56:00.802Z] button-presses.log file Changed
[2018-05-21T00:56:00.813Z] button-presses.log file Changed

但当我们修改一个文件时，回调却执行了 4 次！原因是文件被写入时，可能触发多次写操作，即使只保存了一次。但我们不需要这么敏感的回调，因为通常认为一次保存就是一次修改，系统底层写了几次文件我们并不关心。

因而可以进一步判断是否触发状态是 change:

</>复制代码 
fs.watch(dir, (event, filename) => {
  if (filename && event === "change") {
    console.log(`${filename} file Changed`);
  }
});

这样做可以一定程度解决问题，但作者发现 Raspbian 系统不支持 rename 事件，如果归类为 change，会导致这样的判断毫无意义。

</>复制代码 
作者要表达的意思是，在不同平台下，fs.watch 的规则可能会不同，原因是 fs.watch 分别使用了各平台提供的 api，所以无法保证这些 api 实现规则的统一性。

优化方案一：对比文件修改时间

基于 fs.watch，增加了对修改时间的判断：

</>复制代码 
let previousMTime = new Date(0);
fs.watch(dir, (event, filename) => {
  if (filename) {
    const stats = fs.statSync(filename);
    if (stats.mtime.valueOf() === previousMTime.valueOf()) {
      return;
    }
    previousMTime = stats.mtime;
    console.log(`${filename} file Changed`);
  }
});

log 由 4 个变成了 3 个，但依然存在问题。我们认为文件内容变化才算有修改，但操作系统考虑的因素更多，所以我们再尝试对比文件内容是否变化。

</>复制代码 
笔者补充：另外一些开源编辑器可能先清空文件再写入，也会影响到触发回调的次数。

优化方案二：校验文件 md5

只有文件内容变化了，才认为触发了改动，这下总可以了吧：

</>复制代码 
let md5Previous = null;
fs.watch(dir, (event, filename) => {
  if (filename) {
    const md5Current = md5(fs.readFileSync(buttonPressesLogFile));
    if (md5Current === md5Previous) {
      return;
    }
    md5Previous = md5Current;
    console.log(`${filename} file Changed`);
  }
});

log 终于由 3 个变成了 2 个，为什么多出一个？可能的原因是，在文件保存过程中，系统可能会触发多个回调事件，也许存在中间态。

优化方案三：加入延迟机制

我们尝试延迟 100 毫秒进行判断，也许能避开中间状态：

</>复制代码 
let fsWait = false;
fs.watch(dir, (event, filename) => {
  if (filename) {
    if (fsWait) return;
    fsWait = setTimeout(() => {
      fsWait = false;
    }, 100);
    console.log(`${filename} file Changed`);
  }
});

这下 log 变成一个了。很多 npm 包在这里使用了 debounce 函数控制触发频率，才将触发频率修正。

而且我们需要结合 md5 与延迟机制共同作用，才能得到相对精准的结果：

</>复制代码 
let md5Previous = null;
let fsWait = false;
fs.watch(dir, (event, filename) => {
  if (filename) {
    if (fsWait) return;
    fsWait = setTimeout(() => {
      fsWait = false;
    }, 100);
    const md5Current = md5(fs.readFileSync(dir));
    if (md5Current === md5Previous) {
      return;
    }
    md5Previous = md5Current;
    console.log(`${filename} file Changed`);
  }
});

3 精读

作者讨论了一些实现文件夹监听的基本方式，可以看出，使用了各平台原生 API 的 fs.watch 并不那么靠谱，但这也我们监听文件的唯一手段，所以需要基于它进行一系列优化。

而实际场景中，还需要考虑区分文件夹与文件、软连接、读写权限等情况。

另外用在生产环境的库，也基本使用 50 到 100 毫秒解决重复触发的问题。

所以无论 chokidar 或 node-watch，都大量使用了文中提及的技巧，再加上对边界条件的处理，对软连接、权限等情况处理，将所有可能情况都考虑到，才能提供较为准确的回调。

比如判断文件写入操作是否完毕，也需要通过轮询的方式：

</>复制代码 
function awaitWriteFinish() {
  // ...省略
  fs.stat(
    fullPath,
    function(err, curStat) {
      // ...省略
      if (prevStat && curStat.size != prevStat.size) {
        this._pendingWrites[path].lastChange = now;
      }
      if (now - this._pendingWrites[path].lastChange >= threshold) {
        delete this._pendingWrites[path];
        awfEmit(null, curStat);
      } else {
        timeoutHandler = setTimeout(
          awaitWriteFinish.bind(this, curStat),
          this.options.awaitWriteFinish.pollInterval
        );
      }
    }.bind(this)
  );
  // ...省略
}

可以看出，第三方 npm 库都采取不信任操作系统回调的方式，根据文件信息完全重写了判断逻辑。

可见，信任操作系统的回调，就无法抹平所有操作系统间的差异，唯有统一重写文件的 “写入”、“删除”、“修改” 等逻辑，才能保证在全平台的兼容性。

4 总结

利用 nodejs 监听文件夹变化很容易，但提供准确的回调却很难，主要难在两点：

抹平操作系统间的差异，这需要在结合 fs.watch 的同时，增加一些额外校验机制与延时机制。

分清楚操作系统预期与用户预期，比如编辑器的额外操作、操作系统的多次读写都应该被忽略，用户的预期不会那么频繁，会忽略极小时间段内的连续触发。

另外还有兼容性、权限、软连接等其他因素要考虑，fs.watch 并不是一个开箱可用的工程级别 api。

5 更多讨论

</>复制代码 
讨论地址是：精读《如何利用 Nodejs 监听文件夹》 · Issue #87 · dt-fe/weekly

如果你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。

云服务器 GPU云服务器 nodejs停止监听文件监听 linux监听文件如何利用云存储

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/107952.html

精读《如何在 nodejs 使用环境变量》

摘要：引言本期精读的文章是如何在使用环境变量。介绍了开发与生产环境如何管理环境变量。本地通过调试环境变量既方便又安全。更多讨论讨论地址是精读如何在使用环境变量如果你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。 1 引言本期精读的文章是：如何在 nodejs 使用环境变量。介绍了开发与生产环境如何管理环境变量。这里环境变量指的是数据库密码等重要数据，而不是指普通变量传参。 ...

aaron 2019-08-22 17:58 评论0 收藏0
精读《React PowerPlug 源码》

摘要：今天我们就来解读一下的源码。比较有意思，将定时器以方式提供出来，并且提供了方法。实现方式是，在组件内部维护一个定时器，实现了组件更新销毁时的计时器更新销毁操作，可以认为这种定时器的生命周期绑定了组件的生命周期，不用担心销毁和更新的问题。 1. 引言 React PowerPlug 是利用 render props 进行更好状态管理的工具库。 React 项目中，一般一个文件就是一个类，...

teren 2019-08-23 15:27 评论0 收藏0
精读《怎么用 React Hooks 造轮子》

摘要：可以看到，这样不仅没有占用组件自己的，也不需要手写回调函数进行处理，这些处理都压缩成了一行。效果通过拿到周期才执行的回调函数。实现等价于的回调仅执行一次时，因此直接把回调函数抛出来即可。 1 引言上周的精读《React Hooks》已经实现了对 React Hooks 的基本认知，也许你也看了 React Hooks 基本实现剖析（就是数组），但理解实现原理就可以用好了吗？学的是...

Shihira 2019-08-26 13:22 评论0 收藏0
精读《Serverless 给前端带来了什么》

摘要：前端框架总是带入后端思维，而则是把前端思维带入了后端运维。前端同学对应该尤为激动。而带来了进一步优化的空间。当服务器面临攻击重启磁盘故障时，打开复杂的工作台或登陆后一通操作才能恢复。 1. 引言 Serverless 是一种无服务器架构，让用户无需关心程序运行环境、资源及数量，只要将精力 Focus 到业务逻辑上的技术。现在公司已经实现 DevOps 化，正在向 Serverles...

wizChen 2019-08-26 13:35 评论0 收藏0
精读《Nodejs V12》

摘要：更好的安全性随着的发布，从升级到了，更安全且更易配置。通过使用，程序可以减少握手所需时间来提升请求性能。提供诊断报告有一项实验功能，根据用户需求提供诊断报告，包括崩溃性能下降内存泄露使用高等等。前端精读帮你筛选靠谱的内容。 1. 引言 Node12 发布有几个月了，让我们跟随 Nodejs 12 一起看看 Node12 带来了哪些改变。 2. 概述 Node12 与以往的版本不同，带来...

CoderStudy 2019-08-26 10:25 评论0 收藏0