标签: NestJS

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

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

Session 哪里出了问题

baka_mashiro大约 10 分钟

从自研队列到 Bull：重新设计评测队列

提交链路是 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
  }
}

baka_mashiro大约 9 分钟

从零重建 Online Judge：一次完整的全栈重构记录

有些项目悄悄地积累债务。Leverage OJ 不是其中之一——它大声地积累，表现为比赛中途冻结的排名系统、在 PM2 集群下崩溃的认证系统、每次请求都扫描整个提交表的排行榜，以及离全量凭证泄露只差一个配置泄漏的密码哈希方案。

这是完整重写的故事：我们替换了什么、为什么，以及在这个过程中学到了什么。

1. 为什么选择重写而不是重构

技术债务清单

原版 Leverage OJ 是一个在真实约束下快速推进的项目。开发者是深思熟虑的——你可以从架构决策中看出来。但六年的功能添加、午夜修复和"在我机器上能跑"的补丁已经堆成了一座摇摇欲坠的塔。

baka_mashiro大约 15 分钟

Leverage OJ 重构记：从屎山到干净架构

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

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

为什么要重构？让我数数

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

baka_mashiro大约 6 分钟