几个月前，我开始认真审查 Leverage——一个在生产运行多年的 NestJS Online Judge 平台。零测试。没有 lint 强制执行。没有正式的审查流程。只有在 deadline 压力下一个功能接一个功能长出来的代码。

最终我整理出了 29 个问题。有些是小的风格问题，有六个是那种让你盯着屏幕半天想"这个……一直在跑？"的 bug。

这篇文章讲的是那六个。

审查方法

在深入具体 bug 之前，先说说我的方法论。审查一个大型的、零测试的代码库，靠随机探索是不行的，你会漏掉东西。我用了三个切入点：

1. 用 commit 历史作为 bug 地图。 名字是 fix/issues、hotfix/ranking 这类的分支是金矿。commit message 告诉你开发者知道什么出了问题。倒着读那些 diff——fix 之前的代码就是你要在代码库其他地方寻找的东西。

认证这件事，感觉上早就被解决了——直到你接手一个其实没解决好的代码库。开始重写 Leverage OJ 的时候，我发现认证系统其实是三个问题穿了一件外套：一个在 PM2 下会出问题的 Session 配置、一个演变成独立平行宇宙的 ContestUser 认证体系、以及一套差一次配置泄露就会全库密码暴露的哈希方案。

这些问题都不是一眼能看出来的。系统在运行——用户可以登录，Session 能持久化，比赛能正常进行。但"能运行"和"正确"是两回事，看得越仔细，就越能看到一个基于不再成立的假设运转的系统。

Session 哪里出了问题

提交链路是 Online Judge 的关键路径。用户提交代码，进队列，Worker 取出来，发给评测机，等结果，写回数据库。理论上简单。原版 Leverage 的实现是一个基于 Redis List 的自研队列——问题只在出事的时候才会暴露出来。

这篇文章讲我们为什么要换掉它，换成了什么样，以及一个关于消息投递的边界情况，让我不得不认真思考故障模式。

原来的队列

原代码有一个自研的 Queue<T> 类，底层用 Redis List 操作：

// 原版 queue.ts — 概念上类似这样
class Queue<T> {
  async push(item: T): Promise<void> {
    await this.redis.lpush(this.key, JSON.stringify(item))
  }

  async pop(): Promise<T | null> {
    const result = await this.redis.brpop(this.key, 0) // 阻塞弹出，0=一直等
    if (!result) return null
    return JSON.parse(result[1]) as T
  }
}

每个代码库都有自己的故事。Leverage——我一直在维护的 Online Judge 平台——也有，只是这个故事不太好看。经历了多年的功能叠加、半夜推上去的临时修复、以及偶尔出现的"在我机器上能跑"式 hack 进了生产，这个代码库积累的技术债已经够开一家小公司了。

决定做全量重写不是一时冲动。重写有风险，"第二系统效应"是真实存在的。但当一次代码审查翻出 29 个 bug——包括一个"所有 AC/WA 提交计数都静默出错"的问题——你就会开始重新考虑了。

为什么要重构？让我数数

Bug 1：PM2 Cluster 把功能变成了幽灵

比赛进行期间，Leverage——我维护的 Online Judge 平台——的排行榜停止更新了。持续了大约半天。学生在提交代码、拿到评测结果，但排名没有变化。最终我们把问题追溯到一个每 15 分钟执行的 cron job，它严重地阻塞了 Node.js 事件循环，导致进程几乎不响应。

这篇文章讲的是哪里出了问题、为什么那些"显而易见"的修法实际上什么都没修好，以及 Redis Sorted Set 方案如何用 O(log N) 实时更新彻底替换掉整个 cron job。

原始设计

排名系统是这样工作的：

// rank.service.ts — 简化版
async rebuildSaAndRank(divisionId: number, ids: number[]) {
    // 第一步：加载所有提交
    const submissions = await Submission.createQueryBuilder('s')
        .where('s.divisionId = :divisionId', { divisionId })
        .orderBy('s.createdAt', 'ASC')
        .getRawMany()
    
    // 第二步：在内存里计算每个用户的分数
    const userDatas: Map<UserId, ScoreAggregate>[] = []
    for (const submission of submissions) {
        // ... 处理每条提交，更新用户分数 map
        // 用 cloneDeep 创建完整的每日历史快照
    }
    
    // 第三步：给所有人排序
    const ranked = [...userDatas[0].entries()]
        .sort(([, a], [, b]) => compareScores(a, b))
    
    // 第四步：逐条写回——每个用户一条 UPDATE
    for (const [userId, scoreAggregate] of ranked) {
        await ContestUser.update({ userId, contestId }, {
            rank: /* 计算出的排名 */,
            score: scoreAggregate.score,
        })
    }
}