用 Node 的 fs.watch 监听配置变更,我遇到了重复事件
线上有个服务需要热加载本地 JSON 配置,Node 18.17,Linux 容器,配置大概 200 行,一天改两三次。最初用 fs.watch 监听文件,改了配置后偶尔会连续触发两次回调,导致重载逻辑跑两遍,其中一次读到写了一半的文件直接 JSON.parse 报错。
线上有个服务需要热加载本地 JSON 配置,Node 18.17,Linux 容器,配置大概 200 行,一天改两三次。最初用 fs.watch 监听文件,改了配置后偶尔会连续触发两次回调,导致重载逻辑跑两遍,其中一次读到写了一半的文件直接 JSON.parse 报错。
上个月做定时任务,需要把用户本地时间转换成 UTC 存库。线上用的是 Node 20.11,容器时区统一设成 UTC,数据量不大,一天几十万条记录。上线第二天发现,凌晨那批任务的执行时间比预期晚了一个小时,用户投诉说提醒迟到了。
上周把一个服务从 Node 16 迁到 Node 20.11,CI 用的是 `npm ci`。本地 `npm install` 一切正常,流水线跑第三次构建的时候开始报错,说 `package-lock.json` 和 `package.json` 不同步,直接退出。仓库大小不大,`node_modules` 装完 400MB 左右,依赖树大概 900 个包。
项目里要批量改几十个 JSON 文件的字段,写脚本太啰嗦,我直接用了 `npx json -I -f a.json -e 'this.x=1'`。本机 Node 18.17,macOS 13,npm 9.6,第一次跑就报 `EACCES: permission denied, open '/Users/xxx/.npm/_npx/.../node_modules/.bin/json'`。文件数量不
上周在一台 4 核 8G 的 CentOS 7 机器上,Node 18.17,要把用户上传的 200 多个 mp4 批量转成 720p。每个文件 30MB 到 400MB 不等,用的是 fluent-ffmpeg 包了一层 child_process.spawn。现象很怪:大部分任务正常,个别超过 300MB 的文件会卡住,进程不退出,也不报错,CPU 占用掉到接近 0。
项目是 Node 20.11 + Express 4,一个内部查询接口,返回的商品列表 JSON 平均 40 到 80KB,峰值 2MB 左右。上线后发现客户端首屏慢,抓包看到响应没压缩,于是加 `compression`。第一版图省事,直接默认参数:
环境是 Node 18.17,Ubuntu 22.04,4 核 8G 的机器。要处理的是一批 Nginx access log,单文件 2.1GB,约 1200 万行,目标是统计每个上游服务的 p99 耗时。第一版我用 fs.createReadStream 加手动拼 buffer,按 \n 切,结果跑了一分多钟还偶发丢行,内存也涨到 800MB 左右。
上周处理一个线上问题,需要把一台机器上 2.4GB 的 access.log 按小时切出来,再统计各小时 5xx 的比例。环境是 Node 20.11,Linux,容器里内存只给了 512MB。第一版我图省事用了 `fs.readFileSync` 读整个文件再 split,进程直接被 OOM kill,一次都没跑完。
我在一个订单自动取消的服务里用 setTimeout 做延迟队列,Node 16 环境,单机峰值 30 万延迟任务。现象是运行两天后 RSS 从 300MB 涨到 1.2GB,heap snapshot 里全是 Timeout 对象和闭包。
服务跑在 Node 18.17,Koa 2 起的 HTTP 服务,日志用 pino。之前每个请求入口手动生成一个 traceId,一路当参数往下传,传到第五层 service 的时候就开始有人忘了带。后来换成 AsyncLocalStorage 存上下文,入口中间件里 run 一个 store,业务代码直接取,看起来能一劳永逸。
上周在 Node 18.16 上跑一个批量生成缩略图的服务,输入是 2000 张 5MB 左右的 JPEG,输出 200x200 的 webp。用 sharp 在主线程一张张处理,内存峰值直接飙到 1.2GB,处理速度还慢。后来换成 worker_threads 池,峰值降到 400MB 左右,吞吐量大概翻了一倍。
线上有个离线任务,每天要读一批第三方导出的 JSON 文件,单个 60 到 200MB,Node 版本是 18.17,跑在 4C8G 的容器里。现象是任务刚起来 RSS 就冲到 1.2G 左右,两三个文件轮着处理时偶尔直接被 OOM kill,日志里连异常都没有。