话说在我们 PLCT ArchRV 组,基础设施都是我们自己搭出来的,分工、打标记、追踪状态全部靠 gh: XieJiSS/plct-archrv-pkg-botgh: cubercsl/archrv-pkg-notification-botgh: Ast-x64/plct-archrv-status-worker 实现。近日我们在维护标记和追踪状态时,发现 plct-archrv-pkg-bot (以下简称 bot)在重启时会丢失几条记录。

最开始,怀疑是重启的时候还有数据没写入到磁盘,导致数据丢失。但是经过排查,发现并不太可能,理论上所有的数据都是在修改时当场写入磁盘的。保险起见,增加了使用同步 IO 的 storePackageMarksSync,通过 npm: async-exit-hook 在进程退出时强制保存。然而还是丢数据。

看 log 可以确认,在退出时把内存里的数据全部写入到磁盘了,那丢数据是怎么回事呢?

又开始考虑是不是 race condition,于是通过 npm: lockfile 实现了进程的保护锁,确保同时只有一个 bot 进程在运行。除了没效果以外,效果非常好。看来也不是多进程并行写入的问题。

最后经过排查,发现问题的根源在 exportimport 上。

最小可复现样例如下:

1
2
3
4
5
6
7
8
9
10
11
12
// a.js
let A = [1, 2, 3, null];

function cleanUp() {
A = A.filter(num => typeof num === "number");
}

function showData() {
console.log(A);
}

module.exports = { A, cleanUp, showData };
1
2
3
4
5
6
7
8
// b.js
const { A, cleanup, showData } = require("./a");

A.push(4);
cleanUp();
A.push(5);
A.push(6);
showData(); // 只有 1, 2, 3, 4

可以看到,在执行 cleanUp 之后的数据全部丢失了。这是因为在 a.js 里对 A 重新赋值过后,b.js 里的 Aa.js 里的 A 不再指向同一个对象。

但是,如果采用另一种写法:

1
2
3
4
5
6
7
8
// b.js
const a = require("./a");

a.A.push(4);
a.cleanUp();
a.A.push(5);
a.A.push(6);
a.showData(); // 1, 2, 3, 4, 5, 6

这是为什么呢?我们用 cpp 来翻译一下第一种写法就明白了。

1
2
3
const auto *A = a.A;
a.A = new vector<int>();
// 此时 A 和 a.A 显然已经不再指向同一块内存了

概括一下:把 JS 里面解构赋值拿到的东西当做 &ref 的错误理解(这是常有的事)就会导致这种 inconsistency 的出现。

如果想修复这个问题,需要在 a.js 里面把 A 声明为 const,随后将 Array#filter 替换为自己实现的 in-place filter,详见这个 commit。当然你也可以在 b.js 里始终使用 a.A 的方式来访问 A

来源:https://blog.jiejiss.com/