1. 项目概述为什么我们要从零手写一个企业级OJ在技术面试和日常技能考核中在线判题系统Online Judge OJ早已不是什么新鲜事物。无论是校招时的算法笔试还是公司内部的月度技术练兵一个稳定、高效、安全的OJ系统都是技术团队不可或缺的基础设施。市面上有开源的OJ项目也有成熟的商业产品但对于一个追求技术深度、希望完全掌控核心逻辑或者有高度定制化需求的团队来说从零开始构建一个属于自己的企业级OJ其价值远超一个简单的工具。这不仅仅是一个“造轮子”的过程。通过手写一个C OJ你将直面并发编程、系统安全、资源隔离、网络通信、判题策略等后端开发的核心难题。你会深入理解Linux进程控制、系统调用、容器化技术如cgroup/namespace的底层原理并亲手设计一套高可靠性的任务调度与状态机。这相当于用C这把“手术刀”解剖一个典型的高并发Web服务系统其技术收获远非调用几个现成API可比。我经历过从使用开源OJ到为团队定制开发的全过程深知其中痛点开源系统架构陈旧难以适配云原生环境商业产品黑盒化定制功能响应慢、成本高。自己动手意味着你可以根据业务特点设计最适合的题目类型比如支持图形化交互题、SQL题实现最灵活的权限管理和比赛模式并将系统无缝集成到内部DevOps流程中。接下来我将带你从零开始拆解这个庞大系统的每一个核心模块分享我在构建过程中积累的设计思路、踩过的坑以及那些教科书上不会写的实战技巧。2. 核心架构设计与技术选型一个企业级OJ系统远不止一个接收代码、返回“AC”或“WA”的简单程序。它是一个典型的分布式、高并发、有状态的服务系统。我们需要从全局视角进行设计确保系统的可扩展性、稳定性和安全性。2.1 整体架构分层我将系统划分为五个核心层次这种清晰的分层有助于解耦和团队协作Web前端层负责用户交互。考虑到开发效率和生态我选择了Vue.js Element UI的组合。它足够成熟组件丰富能快速构建出管理后台、题目列表、代码编辑、实时排名等复杂界面。前端通过RESTful API或WebSocket与后端通信。业务网关层这是所有请求的入口。我使用Nginx作为反向代理和负载均衡器它性能强悍能轻松处理静态资源和SSL卸载。在这一层我们还可以实现统一的权限校验如JWT Token验证、限流和请求日志。核心业务层这是系统的“大脑”用C编写。它包含用户管理、题目管理、比赛管理、提交记录查询等所有业务逻辑。我采用了基于MVC模式的轻量级Web框架如Drogon或Crow它们异步性能好能充分发挥C的效率优势。这一层是无状态的可以水平扩展。判题调度层这是OJ的“心脏”也是技术挑战最大的部分。它是一个独立的C守护进程Judge Daemon负责从消息队列如Redis或RabbitMQ中获取判题任务调用沙盒执行用户代码并与编译服务交互。它的设计直接决定了系统的吞吐量和安全性。支撑服务层包括数据库MySQL/PostgreSQL用于持久化业务数据、缓存Redis用于会话、排行榜等热点数据、消息队列用于解耦业务层与判题层以及文件存储用于保存题目测试数据、用户提交的代码等。注意为什么核心业务和判题都用C一致性是关键。判题模块对性能和安全要求极高必须用C/C贴近系统底层。为了让整个技术栈统一减少环境差异带来的运维成本业务层也选用C。虽然初期开发量比用Go或Java大但长远来看在性能优化、内存管理和团队技能聚焦上收益显著。2.2 关键技术选型背后的思考编译服务用户提交的代码需要被编译。我们不能在判题沙盒内进行编译因为编译过程资源消耗大且可能被恶意利用。我设计了一个独立的编译服务集群。判题调度器将源代码和编译指令发送给编译服务编译服务在受控环境中编译成功后将可执行文件路径返回失败则直接返回编译错误信息。编译服务本身也需要资源限制。消息队列选型判题任务具有明显的生产者-消费者模式。业务层生产任务判题层消费任务。Redis的List结构简单高效足以应对中小规模并发。但如果预期任务量巨大需要更完善的消息确认、持久化和死信机制RabbitMQ是更专业的选择。我最初用Redis后期在压力测试下切换到了RabbitMQ其稳定的表现证明了选型的正确性。数据库设计除了常规的用户、题目表提交记录表submissions的设计尤为关键。它需要记录代码、所用语言、提交时间、判题状态Pending, Judging, AC, WA, TLE, MLE, RE, CE等、消耗时间和内存、所在比赛ID等。必须建立合适的索引如user_id,problem_id,contest_id,status的组合索引以应对排行榜、提交历史查询等高频操作。3. 判题核心安全沙盒的实现与资源限制这是OJ系统最核心、最复杂也最容易出安全问题的地方。目标很简单让一段不可信的代码在一个与世隔绝的“牢笼”里运行并精确控制其所能使用的资源CPU时间、实际时间、内存、线程、系统调用等。3.1 为什么不用Docker很多人第一反应是用Docker容器。它确实提供了不错的隔离性。但在OJ场景下直接使用Docker存在严重问题启动开销大每次判题都docker run再docker rm即使有镜像预热其创建和销毁容器的开销对于毫秒级响应的判题任务来说也过于沉重。资源控制不够精细Docker的--cpu-quota和--memory限制是有效的但对单进程的CPU时间片RLIMIT_CPU、栈大小RLIMIT_STACK、输出文件大小RLIMIT_FSIZE等限制需要在容器内再次用setrlimit设置增加了复杂度。安全边界需要非常小心地配置Capabilities和Seccomp策略否则容器内的进程仍有可能逃逸或危害主机。因此工业级的OJ通常采用更底层的方案系统调用拦截 cgroup资源控制。这也是我采用的方案。3.2 基于ptrace和cgroup的沙盒实现我的判题核心是一个独立的C程序我们称之为judger。它的大致工作流程如下准备阶段judger为本次判题任务创建一个唯一的临时工作目录将编译好的用户程序、输入数据文件放入。创建控制进程judger自身fork出一个子进程这个子进程将作为“控制进程”。设置cgroup在控制进程中首先创建一个唯一的cgroup例如在/sys/fs/cgroup/cpu/judge/和/sys/fs/cgroup/memory/judge/下创建一个以任务ID命名的目录。然后将接下来要运行用户代码的“目标进程”的PID写入cgroup的tasks文件。这样目标进程的所有资源就被限制在了这个cgroup内。我们可以在这里精确设置CPU时间上限、内存上限包括swap。目标进程启动与跟踪控制进程再次fork产生“目标进程”。在目标进程中我们通过chroot或pivot_root切换根目录如果需要文件系统隔离通过setuid/setgid切换到一个低权限用户并通过setrlimit设置进程级别的资源限制如RLIMIT_CPU, RLIMIT_AS(内存), RLIMIT_FSIZE, RLIMIT_NPROC等。然后目标进程使用execve系统调用加载并运行用户的程序。系统调用拦截ptrace关键一步来了。控制进程在fork出目标进程前就通过ptrace(PTRACE_TRACEME, ...)请求跟踪目标进程。目标进程一旦调用execve就会收到SIGTRAP信号并暂停。此时控制进程就可以接管通过ptrace(PTRACE_SYSCALL, ...)让目标进程在每次进入和退出系统调用时都暂停这样控制进程就能检查目标进程试图发起的每一个系统调用。白名单过滤我们维护一个允许的系统调用白名单如read, write, exit, brk等。当控制进程检测到目标进程调用了一个不在白名单内的系统调用如fork, execve, connect, open某些敏感文件时立即终止目标进程并判为“运行时错误RE”。收集运行结果控制进程通过waitpid等待目标进程结束获取其退出状态。通过读取cgroup接口如cpuacct.usage获取CPU时间memory.max_usage_in_bytes获取内存峰值和rusage结构体得到精确的资源消耗数据。同时比较目标进程的输出文件与标准答案文件得出判题结果AC, WA, PE等。// 简化的控制进程核心逻辑片段 pid_t target_pid fork(); if (target_pid 0) { // 目标进程设置资源限制和权限 setrlimit(RLIMIT_CPU, rlim_cpu); setrlimit(RLIMIT_AS, rlim_mem); setuid(JUDGE_USER_UID); // 请求父进程跟踪 ptrace(PTRACE_TRACEME, 0, nullptr, nullptr); // 执行用户程序 execve(user_program_path, argv, environ); exit(EXIT_FAILURE); // execve失败才执行到这里 } else { // 控制进程跟踪并过滤系统调用 int status; while (true) { waitpid(target_pid, status, 0); if (WIFEXITED(status) || WIFSIGNALED(status)) break; // 进程结束 // 获取系统调用号 struct user_regs_struct regs; ptrace(PTRACE_GETREGS, target_pid, nullptr, regs); long syscall_no regs.orig_rax; // x86_64 if (isSyscallForbidden(syscall_no)) { kill(target_pid, SIGKILL); result RuntimeError; break; } // 放行继续执行到下一个系统调用入口/出口 ptrace(PTRACE_SYSCALL, target_pid, nullptr, nullptr); } // 收集资源使用信息 collect_resource_usage_from_cgroup(task_id); }实操心得ptrace的拦截是性能瓶颈之一因为涉及大量的进程上下文切换。优化手段包括1) 将白名单检查逻辑编译成高效的位图或Bloom Filter。2) 对于非常高频且安全的系统调用如brk可以考虑在特定阶段临时关闭ptrace拦截但必须极其谨慎。3.cgroup v2比v1管理更统一建议在新系统上直接使用v2。3.3 应对多种编程语言不同的语言需要不同的处理策略编译型语言C/C如上所述先由编译服务生成可执行文件再由沙盒运行。解释型语言Python, JavaScript沙盒中运行的不是用户代码而是解释器如python3。我们需要将用户代码写到一个临时文件中然后将这个文件路径作为参数传给解释器。资源限制同样作用于整个解释器进程。这里要特别注意需要限制解释器导入import/require危险模块的能力有时需要通过修改Python的site.py或使用sys.settrace来拦截。Java需要先由javac编译然后沙盒运行java命令。JVM自身内存开销很大在设置内存限制时需要将JVM的堆内存-Xmx设置得比cgroup内存限制小不少为JVM自身和系统库留出空间。4. 高并发任务调度与状态机设计当系统面临每秒上百甚至上千的提交时高效的调度至关重要。判题服务Judge Daemon通常以多进程或多线程池方式运行从消息队列中拉取任务。4.1 判题状态机一次提交的生命周期由清晰的状态机驱动Pending-Compiling-Judging-Finished(AC/WA/TLE/...)/Compile Error此外还可能存在System Error判题机内部故障状态。Judge Daemon在拉取到一个Pending任务后首先将其状态更新为Compiling然后调用编译服务。编译成功后更新为Judging进入沙盒执行流程。每一步状态变更都需要原子性地更新数据库并可能通过WebSocket向前端推送实时更新。4.2 避免重复判题与任务丢失这是一个典型的分布式事务问题。我采用的方案是基于数据库的乐观锁。判题机从消息队列取出任务包含submission_id。立即执行一条SQLUPDATE submissions SET status Compiling, judge_node node_id, version version 1 WHERE id ? AND status Pending AND version ?。检查该SQL的affected_rows。如果为1说明成功抢占了该任务如果为0说明任务已被其他判题机处理当前判题机直接丢弃此消息即可。后续每个状态变更都带上版本号进行更新。这种方式避免了在复杂的分布式锁利用数据库的行锁保证了状态变更的原子性。4.3 容错与重试机制网络抖动、编译服务临时不可用、沙盒意外崩溃等情况都可能发生。编译失败直接更新状态为Compile Error并存储编译错误信息。判题过程系统错误将任务状态回退到Pending或一个特殊的Retry状态并重新抛回消息队列。需要为任务设置重试次数上限如3次超过则标记为System Error并报警通知人工介入。判题机宕机每个判题机定期向数据库写入“心跳”。一个监控进程可以检测长时间处于Compiling或Judging状态且对应判题机心跳超时的任务将其重置为Pending由其他健康节点重新处理。5. 核心模块详解题目与测试数据管理题目是OJ的血液。一个企业级系统需要支持丰富的题型和灵活的数据管理。5.1 题目元信息设计题目表problems除了包含标题、描述、输入输出说明、时空限制等基础字段还应包含difficulty难度等级用于推荐和筛选。tags标签数组如[“动态规划” “图论”]用于分类。is_public是否公开可见。source题源如“内部原创”“LeetCode改编”。submit_count/accept_count用于计算通过率实时更新。题目描述建议使用Markdown格式存储前端用相应渲染器展示这样可以方便地插入数学公式KaTeX、代码片段等。5.2 测试数据的管理与安全测试数据是OJ的核心资产必须严格保密。存储不应放在数据库里而是放在文件系统或对象存储如MinIO中。数据库只存储文件的路径索引。我采用按题目ID分目录存储的方式如/data/testdata/1001/1.in,1001/1.out,1001/2.in...加密对于特别敏感的题目如招聘考题可以对测试数据文件进行对称加密如AES判题时在沙盒启动前由判题机用密钥解密到内存或临时文件。密钥由配置中心或KMS管理。版本控制题目修改后测试数据可能更新。我们采用类似Git的方式每次更新都生成一个新的版本目录如1001/v2/并将题目的当前版本指向它。旧的提交记录依然关联旧版本数据保证历史判题结果的可重现性。特殊题型Special Judge某些题目答案不唯一如浮点数误差、最优解验证。需要上传一个SPJ程序通常是C或Python编写。判题时沙盒运行用户程序得到输出然后运行SPJ程序传入输入文件、用户输出、标准输出由SPJ返回判题结果。交互题用户程序需要与一个裁判程序实时交互。这需要更复杂的沙盒间通信机制通常通过管道pipe或共享内存实现并由一个中间控制器协调两者运行。6. 比赛与排名系统实现比赛是OJ最活跃的功能。支持多种赛制是关键。6.1 比赛模式OI赛制比赛期间只显示样例是否通过比赛结束后统一评测并排名。实现简单只需在比赛期间将提交状态标记为“Pending隐藏”赛后由管理员触发批量重判。ACM/ICPC赛制实时评测实时排名。排名规则复杂按解题数从多到少排名解题数相同按罚时从少到多排名。罚时 每道题首次AC的时间 错误提交次数 * 罚时单位通常20分钟。IOI赛制题目有部分分。需要为每道题设置多个测试点每个测试点有独立分值。判题时需要汇总所有测试点得分。排名按总分。6.2 实时排名计算与优化实时排名在比赛期间查询频率极高直接对submissions表进行聚合查询GROUP BY user_id, problem_id计算最早AC时间、错误次数在数据量大时会导致数据库压力巨大。我的优化方案是使用Redis维护实时排名榜。每当有新的提交被判定为AC时判题服务除了更新数据库还向Redis发布一个事件。一个独立的排名计算服务Ranker订阅这些事件。它从Redis或数据库中获取该用户在该题目上的最新状态重新计算该用户的解题数、总罚时和总得分。Ranker将计算结果写入一个Redis的Sorted Set中。Sorted Set的score是排名依据可以设计一个复合分数如(解题数 40) | (MAX_PENALTY - 总罚时)member是用户ID。前端查询排名时直接ZREVRANGE这个Sorted Set即可性能是O(log N)。比赛结束后可以将最终的Sorted Set持久化到数据库。对于历史排名查询可以预先计算好快照。7. 运维、监控与性能调优系统上线后稳定的运维和清晰的监控至关重要。7.1 日志与监控结构化日志所有服务Web业务、判题机、编译服务都输出结构化的JSON日志统一收集到ELK或Loki中。日志必须包含请求ID以便追踪一个提交流经的所有服务。关键指标监控业务层QPS 接口响应时间 错误率。判题层队列堆积长度 平均判题耗时 各结果状态AC/TLE/RE...的比例 沙盒启动失败率。系统层服务器CPU、内存、磁盘IO 数据库连接数。使用Prometheus采集指标Grafana制作仪表盘。告警对队列积压超过阈值、判题失败率升高、服务心跳丢失等情况设置告警。7.2 性能调优实战经验数据库连接池业务层必须使用连接池如sqlpp11配合连接池。我遇到过因未用连接池在并发稍高时迅速耗光数据库连接数导致服务雪崩的情况。判题机资源隔离一台物理机或虚拟机可以运行多个判题机进程但必须为每个进程分配独立的cgroup子树避免它们之间资源竞争。同时要监控整机的资源水位实现动态权重调度将任务更多地分配给空闲的判题机。测试数据预加载判题机在启动时可以将常用题目的测试数据预热到内存如使用mmap避免每次判题都从磁盘读取这对IOPS是巨大的提升。前端资源优化代码编辑器如Monaco Editor、实时排名榜WebSocket推送都是资源消耗大户。要做好分页、虚拟滚动并对长时间不活动的页面断开WebSocket连接以节省服务器资源。8. 安全加固与防作弊策略OJ系统面临独特的安全挑战既要防止用户代码攻击服务器也要防止用户之间的作弊。8.1 系统安全沙盒逃逸这是我们防御的重点。除了严格的系统调用白名单还要定期更新白名单关注Linux内核新系统调用的风险。使用Seccomp-BPF进行更精细的系统调用过滤允许指定参数范围。考虑使用namespace进行网络、PID、挂载点的隔离与cgroup形成纵深防御。拒绝服务防止用户提交死循环代码耗尽判题资源。通过cgroup的pids.max限制进程数通过cpu.cfs_quota_us严格限制CPU时间。在调度层面对单个用户或IP设置提交频率限制。Web安全业务层需防范常见的Web漏洞如SQL注入、XSS、CSRF等。所有用户输入必须经过严格的校验和过滤。8.2 反作弊代码查重对于比赛赛后进行代码相似度检测是必要的。可以使用基于AST抽象语法树的查重工具如JPlag、MOSS的API它能比简单的文本比较更有效地检测出变量重命名、结构调整等抄袭手段。异常行为检测监控同一题目在极短时间内大量相似通过率极低的提交可能是爆破答案的脚本。监控比赛中的提交模式例如如果一个用户总是在题目发布后极短时间内短于正常人读题时间提交并AC可能是作弊信号。比赛环境隔离重要比赛可以启用“比赛密码”、限制参赛IP段、要求开启摄像头监控等物理防作弊手段。从零构建一个企业级OJ系统是一次充满挑战的旅程它几乎涵盖了后端工程师需要面对的所有核心问题高并发架构、安全编程、资源管理、状态设计、性能优化。这个过程会让你对Linux系统、C网络编程、数据库有脱胎换骨的理解。当你看到自己打造的系统稳定承接起公司数百人的技术竞赛时那种成就感是无与伦比的。我建议你在实现基础功能后可以尝试拓展更多有趣的方向比如支持在线IDE、集成代码风格检查、或者利用判题集群做分布式压力测试让这个系统衍生出更大的价值。
