背景

在经过第一次线下拉数据以后，紧接着更危险、更刺激的刷数据环节来啦！

刷数据这件事儿非常的危险，因为涉及手动将数据写入到数据库，而且还会对用户侧有直接的影响。

拉数据吧，是个读操作，读错第一次，还可以读第二次、第三次、第四次、。。。第N次。。（都是泪😢）

但写数据这事儿，要么对，要么错。要是错了，真的是欲哭无泪 。写错了，用户会直接感知到。写错一个数据，真的会非常非常的麻烦。轻则求运营安抚用户，重则Say goodBye to my favorite work!

这种事儿临近年中啊，年终啊，有考核节点前切记莫干。尤记得曾经一位server年终刷数据失误，导致用户收到错误的短信消息，抑郁好久，甚是忧心自己的年终奖。

Fire Ritual by Kazuo Shiraga in 1974

开发经过

PM侧给过来的是一份Excel表格，取第一列的用户的uid。（类似于👇）

复制粘贴到vscode中，很好，是一列数字。

利用nodeJS的fs系统，一行一行读即可。

// 读取文件，然后用\n拆分开
const fileContent = fs.readFileSync(blackUidListFilePath, 'utf-8').toString();
const uidListArr = fileContent.split('\n');

// 再创建新的文件，将其用“,\n”拼接，写入到新的文件中。
fs.mkdirSync(fileListDirPath);
fs.open(path.join(fileListDirPath, 'uid.ts'), 'a+', (err, fd) => {
    if (err) {
        console.log(err);
    }
    fs.appendFileSync(fd, `var a = [\n${uidListArr.join(',\n')}\n]`, 'utf8');
});

感觉还挺完美哈！ BUT，发现这些数据有很多 'E+'的格式，原因是这些数字太长了，Excel默认将其用科学记数法显示了。

于是！我手动处理了10个左右，接着往下滚动列表发现还有很多，心想这也太费时了吧（暗自心疼自己❤️）。。。

然后一拍脑袋，百度呀！遂百度怎么正常显示这些科学计数法的数字。

发现，原来改个显示方式即可，把默认的【常规】改为【数字】（。。。不要笑😅😅😅😅。。。）

赶紧处理完数据。（此时短暂且宝贵的上午时光已消逝）

下午开始处理改写接口啦，这部分就是处理代码的业务逻辑。心想昨天已经有过拉数据的经验，这次问题应该不大。（还是太年轻，想的太简单😢）

处理日志部分复用第一次线下拉数据中用到的方式：

fs.appendFileSync(`result-uid-detail-${timeR}.csv`, `A,B,C,D,E\n`);
for (const item of musicianMap) {
  console.log('writing......');
  fs.appendFileSync(`result-uid-detail-${timeR}.csv`, `${item.uid},${item.name},${item.fanCount},${item.passedSongCount},${item.songCount}\n`);
}

这次要刷的数据分为两波，一波是白名单，另一波是黑名单。

后在处理黑名单时，由于运营给错了白名单的uid，遂又刷了一波白名单。

第一次刷白名单，测试了大半天，而且改写的代码是在原有的接口上。因此在刷黑名单时，直接将白名单的改动全部 Reset 回去了！

弄啊弄啊，时间又到了晚上的时光啦！此时卡在了一个点上，发现写出来的黑名单的数据记录怎么也不对！刷了几个真实数据，验证了下数据的状态是正确的。

运营开始来催啊催了！心情开始烦躁，还告诉我白名单错了！要重新刷，心里 maimaipi 自己👋。

于是开始硬着头皮处理完了黑名单。

此时，需要开个会（10点了！）。。。暴风哭泣。。

10点半，开始处理白名单处理，此时心已冷静下来，10分钟就写完了脚本，这次是新写的接口，留下备份测试了一下，稍加改正就通过了，然后跑真实数据，不到3min就结束啦！

本次事件的lucky之处：

运营需要白名单中处理的数据量，（还好这部分日志，我是有正确记录的！）
运营在后台可以查到黑名单处理的数据量（这部分日志，恰好是我没有正确记录的！）

本次极大改进之处：

刷数据分支记得保留
脚本记得自己验证下，记录一定要正确
深呼吸，深呼吸，冷静，冷静！

经验总结

刷数据，记得多测试。并且用自己的数据进行测试。

刷数据基本步骤（姿势）：

用nodejs处理文本，获取到要处理的数据源
替换原有线上接口，编写新的接口，处理【刷数据逻辑】
编写日志，记录修改和操作的数据信息
利用前端触发，在测试账号进行测试，重点关注最终的写入数据，push消息，以及输出的文件记录是否正确。
造测试数据，多测几遍
观察下要刷的数据的量，判断是否需要分多次，避免接口超时
前端界面触发，开跑！！🏃
将记录的操作的数据的量反馈给PM（or 运营）

刷数据这件事儿，能拒绝先拒绝!!！（风险较大呀，收益不高啊，不合规啊，没时间啊。。。等等）

万不得已，熟能生巧！Good luck！

纪念下第一次刷数据

背景

开发经过

经验总结