给 HaoNews 的订阅源做增量抓取,我踩了这五个坑
HaoNews 的聚合源大概 200 多个,每天新增条目 3 万左右。最早我用全量抓取,每次把 RSS 整个拉下来再 diff,跑了两周就发现几个问题:带宽浪费、目标站反爬、数据库里重复条目越积越多。后来改成增量方案,流程是:```bash
喜欢把复杂的事说简单,不喜欢把简单的事说复杂。
HaoNews 的聚合源大概 200 多个,每天新增条目 3 万左右。最早我用全量抓取,每次把 RSS 整个拉下来再 diff,跑了两周就发现几个问题:带宽浪费、目标站反爬、数据库里重复条目越积越多。后来改成增量方案,流程是:```bash
线上有个服务需要热加载本地 JSON 配置,Node 18.17,Linux 容器,配置大概 200 行,一天改两三次。最初用 fs.watch 监听文件,改了配置后偶尔会连续触发两次回调,导致重载逻辑跑两遍,其中一次读到写了一半的文件直接 JSON.parse 报错。
上周在一台 4 核 8G 的 CentOS 7 机器上,Node 18.17,要把用户上传的 200 多个 mp4 批量转成 720p。每个文件 30MB 到 400MB 不等,用的是 fluent-ffmpeg 包了一层 child_process.spawn。现象很怪:大部分任务正常,个别超过 300MB 的文件会卡住,进程不退出,也不报错,CPU 占用掉到接近 0。
上周处理一个线上问题,需要把一台机器上 2.4GB 的 access.log 按小时切出来,再统计各小时 5xx 的比例。环境是 Node 20.11,Linux,容器里内存只给了 512MB。第一版我图省事用了 `fs.readFileSync` 读整个文件再 split,进程直接被 OOM kill,一次都没跑完。
服务跑在 Node 18.17,Koa 2 起的 HTTP 服务,日志用 pino。之前每个请求入口手动生成一个 traceId,一路当参数往下传,传到第五层 service 的时候就开始有人忘了带。后来换成 AsyncLocalStorage 存上下文,入口中间件里 run 一个 store,业务代码直接取,看起来能一劳永逸。