1. 从零到一为什么DomJudge是算法竞赛的首选平台如果你负责过学校、公司或者社区的算法竞赛或者你是一个热衷于自己出题、组织线上比赛的开发者那你一定绕不开一个名字DomJudge。我第一次接触它是在为一个校级的编程马拉松Hackathon寻找评测系统的时候。当时市面上有各种选择从商业闭源的到一些轻量级的开源方案。折腾了一圈最后发现对于需要高度自定义、完全掌控在自己手里并且对稳定性和公平性有苛刻要求的场景DomJudge几乎是唯一且最优的答案。简单来说DomJudge是一个功能完整、开源免费的自动评测系统Online Judge。它的核心工作流程和我们熟知的LeetCode、Codeforces等平台在逻辑上是一致的参赛者提交代码系统在后台编译、运行用预设的测试数据去验证然后返回一个结果Accepted, Wrong Answer, Time Limit Exceeded等。但DomJudge的独特之处在于它不是一个“服务”而是一个你可以完全部署在自己服务器上的“工具包”。这意味着所有的数据题目、提交、用户信息都掌握在你手里你可以定制评测环境、修改界面、集成到自己的认证系统甚至调整评测的核心逻辑。为什么我最终选择了它原因很直接可控性和专业性。商业平台虽然省事但往往有题目数量、比赛模式、评测环境等方面的限制你很难为一个特殊的赛制比如结合硬件交互的IoT题目去定制评测机。而一些更轻量的开源方案可能在功能完整性上有所欠缺比如对多种编程语言的支持、对SPJSpecial Judge特判程序的友好度或者比赛过程中的实时榜单刷新机制。DomJudge在这几点上做到了一个很好的平衡——它足够复杂和强大能支撑国际大学生程序设计竞赛ICPC区域赛级别的需求同时它的架构又足够清晰让有经验的系统管理员能够理解和调整。所以这篇内容就是基于我多次部署、配置DomJudge并成功举办多场比赛的实战经验来详细拆解两个最核心、也最容易让人头疼的环节题目配置和开比赛。我会假设你已经完成了DomJudge的基础安装这本身也是一个值得大书特书的话题但限于篇幅我们聚焦在应用层服务器在正常运行Web界面可以访问。我们的目标是让你能独立完成从一道题目的创建、测试到成功组织一场包含多道题目的完整比赛的全过程。过程中我会穿插大量只有踩过坑才知道的细节和技巧希望能帮你避开我当年走过的弯路。2. 题目配置详解一道好题是如何“炼”成的配置一道题目远不止是写一个题目描述和几组测试数据那么简单。在DomJudge的体系里一道题目是一个包含元数据、评测数据、特判程序等在内的完整“包”。理解这个“包”的结构是高效出题的关键。2.1 题目包的目录结构与核心文件DomJudge采用一种非常清晰的文件系统结构来管理题目。通常我们会为每一道题创建一个独立的目录比如problem_a/。在这个目录下你需要组织以下核心文件problem_a/ ├── problem.yaml # 题目的元数据配置文件最重要 ├── problem_statement/ # 题目描述文件夹 │ └── problem.tex # 或 problem.md 题目正文 ├── data/ # 评测数据文件夹 │ ├── secret/ # 隐藏的测试数据正式评测用 │ │ ├── sample01.in │ │ ├── sample01.ans │ │ ├── test01.in │ │ └── test01.ans │ └── sample/ # 样例数据对选手可见 │ ├── sample01.in │ └── sample01.ans └── submissions/ # 可选参考解答/错误解答用于验证 ├── accepted/ # 正确的解法 │ └── ac_solution.cpp ├── wrong_answer/ # 会输出错误答案的解法 └── time_limit_exceeded/ # 会超时的解法problem.yaml文件这是题目的灵魂。它定义了题目的所有属性。一个最基础的配置可能长这样name: A B Problem limits: memory: 256 # 内存限制单位MB output: 64 # 输出限制单位MB time: 1.0 # 时间限制单位秒 validation: default # 验证方式默认是逐字节比较但实际比赛中我们需要配置的远不止这些。下面是一个更完整的示例包含了多个关键字段name: Complex Problem limits: memory: 1024 output: 256 time: 2.0 validation: custom # 使用自定义校验器Special Judge validator: checker.cpp # 指定校验器文件名 validator_flags: -Wall -O2 # 编译校验器的参数 run: compare: diff # 默认比较器当validation为default时使用 args: -i # 给比较器的参数例如 -i 表示忽略大小写注意time限制的单位是秒并且支持小数。对于CPU密集型题目设置需要非常精确。一个常见的坑是你在本地用time命令测试的时间和DomJudge在隔离环境中运行的时间可能有差异通常DomJudge会略慢一点。因此给时间限制留出10%-20%的余量是明智的。data/secret/目录这里存放所有用于正式评测的输入.in和答案.ans文件。文件名没有硬性规定但通常按顺序命名如test01.in,test02.in... DomJudge会遍历这个目录下的所有.in文件用对应的.ans文件进行比对。非常重要的一点.ans文件是“标准答案”的输出。对于使用默认逐字节比较的题目选手程序的输出必须和.ans文件完全一致包括末尾的换行符。多一个空格、少一个换行都会导致Wrong Answer。data/sample/目录这里的样例数据会在题目描述页面向选手展示。通常我们会把一两组最简单、最能说明问题的测试数据放在这里帮助选手理解输入输出格式。样例数据不会用于正式评测。2.2 测试数据的生成与验证确保公平性的基石创建高质量的测试数据是出题中最耗时也最需要细心的部分。数据不仅要覆盖各种边界情况还要保证其正确性。1. 数据生成策略手写小数据用于验证逻辑的基本正确性。通常sample/里的数据和secret/里前几组数据可以手写。脚本生成大数据用Python、C等编写数据生成器generator.cpp。这是主流方法可以确保数据规模、随机性符合要求。例如生成一个包含10万个随机数的数组用于排序算法测试。极端数据专门构造让低效算法超时或爆内存的数据。例如针对图论题目生成链状、星状、完全图等特殊结构的测试点。2. 验证流程必须在你把数据放入secret/目录前必须用你准备好的“标程”至少一个完全正确的解法跑一遍所有数据生成对应的.ans文件。流程如下# 假设你的标程是sol.cpp 数据生成器是gen.cpp g -O2 -stdc17 sol.cpp -o sol g -O2 -stdc17 gen.cpp -o gen # 生成10组测试数据 for i in {01..10}; do ./gen data/secret/test$i.in ./sol data/secret/test$i.in data/secret/test$i.ans done关键技巧生成.ans文件后务必用肉眼或者写一个简单的脚本检查一下前几组数据的输出是否合理。我曾经犯过一个错误数据生成器里的随机数种子没设置好导致生成的数据违背了题目约束条件比如生成了负数但题目说全是正整数结果标程跑出来的答案本身就是错的导致所有提交都莫名其妙WA排查了很久。3. 使用submissions/目录进行自动化验证这是DomJudge一个非常强大的功能。你可以在submissions/下放置各种类型的解答程序accepted/放你认为正确的解法可以放多种不同思路的用于交叉验证。wrong_answer/,time_limit_exceeded/,runtime_error/放一些你知道会出错的解法。在DomJudge的题目导入界面或使用命令行工具时可以指定用这些提交来“验题”。系统会自动用这些程序去跑你的测试数据然后看评测结果是否符合你的预期例如accepted/里的程序全部ACwrong_answer/里的程序全部WA。这能在赛前最大限度地发现题目和数据的问题。2.3 特判程序Special Judge的集成很多题目不是简单的输出匹配比如浮点数精度误差允许在一定范围内1e-6。输出方案不唯一只要符合要求即可如图的任意一种拓扑序。输出格式比较灵活如忽略多余空格和换行。这时就需要编写特判程序Checker。在problem.yaml中你需要设置validation: custom并指定validator。一个典型的Checker用C编写会从标准输入读取选手输出、标准答案和测试数据输入可选然后根据逻辑判断并返回结果。DomJudge对Checker的返回值有明确约定#include bits/stdc.h using namespace std; int main(int argc, char** argv) { // argv[1] 是测试数据输入文件路径 // argv[2] 是标准答案文件路径 // argv[3] 是选手输出文件路径 // 此外标准输入也可以用于读取更多信息如果problem.yaml中配置了 ifstream in_ans(argv[2]); ifstream in_out(argv[3]); double jury_out, user_out; in_ans jury_out; in_out user_out; // 示例检查相对误差或绝对误差在1e-6内 if (abs(jury_out - user_out) 1e-6 || abs(jury_out - user_out) / max(1.0, jury_out) 1e-6) { cout AC endl; // 返回 Accepted } else { cout WA endl; // 返回 Wrong Answer } // 还可以返回其他信息如 PC部分正确等需在problem.yaml中定义相应评分逻辑 return 0; }踩坑实录Checker本身的鲁棒性至关重要。它必须能处理选手输出任何可能的情况——格式错误、非数字、文件过早结束等。一个脆弱的Checker可能导致正确程序被判WA或者更糟让Checker自己运行时崩溃导致评测结果为Internal Error这是比赛事故。务必用submissions/目录里的各种错误程序充分测试你的Checker。3. 比赛创建与流程控制打造一场丝滑的赛事体验题目准备好了接下来就是如何把它们组织成一场比赛。DomJudge的比赛管理功能非常灵活可以模拟ICPC、IOI等多种赛制。3.1 比赛创建与基本参数设置在DomJudge的Web管理界面进入“Contests”页面创建新比赛。以下几个参数需要特别关注比赛名称与IDID会用于生成榜单的URL建议用英文短标识如spring2024_final。激活时间与开始时间Activate Time比赛在榜单上可见的时间。可以早于开始时间让选手提前看到题目列表但看不到内容和熟悉界面。Start Time比赛正式开始的时刻选手可以提交代码。Freeze Time榜单冻结时间。在此时间后的提交不会实时更新到公开榜单上这是ICPC赛制的经典设置用于增加悬念。End Time比赛结束时间。结束后选手通常可以继续提交但不再计入排名取决于设置。Unfreeze Time榜单解冻时间公布最终结果。Deactivate Time比赛完全隐藏的时间。时间设置的坑DomJudge服务器的时间是基准。务必确保服务器时间准确并使用一致的时区建议全部使用UTC时间进行设置避免本地时区转换带来的混乱。我曾经因为服务器时区设置错误导致比赛提前一小时开始造成了不小的混乱。赛制最常用的是ICPC和IOI。ICPC罚时制。每道题从比赛开始到首次AC的时间计入解题时间错误的提交在AC后每次增加20分钟罚时。未AC的题目不计罚时。这是最经典的算法竞赛赛制。IOI积分制。每道题有多个测试点按通过测试点的比例得分。适合有部分分概念的比赛。Scoreboard Type选择pass仅显示通过数或score显示具体分数。3.2 题目添加、顺序与分值配置在比赛创建后进入“Problems”标签页添加题目。你可以从已导入DomJudge的题目库中选择。题目顺序在比赛编辑界面你可以拖拽调整题目在列表中的显示顺序。通常按照难度递增排列A题最简单。但也可以设置“乱序”让不同队伍看到的题目顺序不同防止抄袭。颜色与标签可以为每道题分配一个颜色如A题红色B题蓝色这会让榜单和题目列表更直观。也可以添加标签如graph,dp但通常对选手不可见用于内部管理。分值对于ICPC赛制所有题目的分值在榜单上通常显示为1解题数。但对于IOI或自定义赛制可以设置每道题的分值。一个高级技巧你可以在problem.yaml中为每个测试点设置细分分值实现IOI式的部分评分。这需要在problem.yaml中配置scoring部分。关联题目与比赛的陷阱题目本身是全局资源一场比赛只是“引用”了这些题目。这意味着如果你在比赛开始后修改了题目包比如更新了数据所有引用这道题的比赛都会受到影响对于已经开始的比赛这是极其危险的操作。正确的做法是在比赛开始前彻底冻结题目包。如果必须修改可能需要克隆一道新题并替换比赛中的题目引用操作非常繁琐。所以赛前充分验题至关重要。3.3 队伍与用户管理权限与分组策略参赛者需要通过账户登录DomJudge提交代码。管理方式主要有两种DomJudge本地账户直接在DomJudge的“Teams”和“Users”页面创建。可以为每个队伍创建一个团队账户也可以为每个成员创建个人账户然后关联到团队。这种方式简单直接适合中小型比赛。外部认证集成DomJudge支持通过IP地址认证或者通过API与外部系统如学校的LDAP/SSO集成。对于大型比赛通常采用后者选手用学号/工号登录后台自动同步队伍信息。关键配置点团队类别可以创建不同的类别如“正式队伍”、“打星队伍”、“裁判组”。不同类别可以决定是否参与排名sortorder。打星队伍的提交不会出现在正式榜单中。用户角色team角色是参赛者admin角色是管理员judge角色是裁判可以查看提交详情但不能修改比赛设置。合理分配权限。团队房间与位置对于线下赛可以分配队伍到具体的物理房间和座位号方便现场管理和作弊防控。3.4 比赛进行中的监控与干预比赛开始后管理员和裁判的主要工作平台是“Submission”和“Scoreboard”页面。提交列表这里实时显示所有提交包括结果。你可以点击查看具体代码、评测详情。对于Internal Error评测系统内部错误的提交需要立即检查这往往是题目数据或特判程序有问题。榜单监控榜单的实时变化。DomJudge的榜单刷新有短暂的缓存通常几秒到十几秒这是正常的。广播信息可以通过“Clarification”系统发布全局公告或者回复队伍关于题目的疑问Clarification Request。处理Clarification的原则是只回答题目描述中确实存在的歧义不回答任何解题思路相关的问题。所有有意义的问答都应该公开确保对所有队伍公平。重判如果发现某道题的数据或特判程序有严重问题可能需要对所有该题的提交进行重判。这是一个重量级操作在DomJudge的“Jury”界面有相应功能。重判前务必备份数据库并确保新的评测数据/程序100%正确。4. 实战避坑指南与高阶技巧理论说完了下面分享一些只有实际踩过坑才能积累的经验这些细节往往决定了一场比赛的成败。4.1 环境隔离与安全防止“黑魔法”攻击DomJudge的评测是在严格隔离的容器默认使用chroot或cgroup中进行的。但作为管理员你必须意识到潜在的风险系统调用限制DomJudge的runguard工具会限制被评测程序可以使用的系统调用。默认配置对于大多数算法竞赛题目是安全的。但如果你允许提交某些“不安全”语言如C/C选手程序理论上可以尝试调用fork,exec,connect等系统调用来破坏评测机或攻击网络。你需要根据题目需求在DomJudge的全局配置或题目级别的problem.yaml中调整systemcalls白名单。例如如果一个题目允许使用多线程就需要开放pthread相关的系统调用。文件描述符与内存限制除了problem.yaml里设置的time和memory评测环境还有打开文件数、进程数等限制。对于极端情况如故意创建无数线程耗光资源的防御依赖于底层操作系统的配置和runguard的设置。建议在赛前用恶意代码进行压力测试。编译器版本与标准库明确告知选手服务器上各语言编译器的版本和编译选项如g 11.3.0 -O2 -stdc17。不同版本编译器对标准库的实现、未定义行为的处理可能有差异这可能导致选手本地AC而线上WA。在problem.yaml中可以通过compile脚本自定义编译命令但通常使用系统默认即可。4.2 性能调优与压力测试一场几百人同时进行的比赛在开始后的几分钟内可能会涌入上千次提交。评测队列可能会积压。评测机数量DomJudge支持分布式评测。你可以部署多台评测机Judging Daemon。在管理界面可以添加新的评测机主机。确保评测机与主服务器之间的网络延迟低并且评测机本身有足够的CPU和IO性能特别是对于大量随机读写的测试数据。数据库优化DomJudge重度依赖数据库通常是MySQL/MariaDB。对于大型比赛确保数据库配置了足够的连接数并且innodb_buffer_pool_size设置合理能缓存大量数据。赛前可以对数据库进行压力测试模拟高并发提交。缓存与静态文件DomJudge的Web界面会加载很多静态资源。使用Nginx或Apache作为前端反向代理并配置好静态文件缓存可以显著减轻PHP后端的压力。实战压力测试在比赛前组织一批测试账号编写脚本模拟在短时间内集中提交所有题目的代码。观察服务器负载、评测队列延迟和Web界面响应速度。我常用的方法是写一个Python脚本用requests库模拟登录和提交并发数设置在50-100左右持续跑几分钟。4.3 备份与应急恢复预案“永远要有Plan B。” 这是组织线上比赛的第一信条。完整备份赛前对整个DomJudge的目录尤其是/opt/domjudge和数据库进行完整备份。数据库备份命令mysqldump -u [user] -p domjudge backup.sql。快照回滚如果比赛平台部署在云服务器上在比赛开始前一刻为整个虚拟机创建一个快照。如果比赛中出现不可恢复的严重故障如误删题目、数据库崩溃可以快速回滚到快照状态。虽然会丢失一些提交数据但比比赛完全中断要好。紧急题目修正流程如果比赛中发现某道题有非改不可的错误如描述歧义导致全场无人能懂流程应该是立即通过广播系统通知所有队伍。在后台克隆该题目生成一道新题如problem_a_v2。修正新题目的描述或数据。在比赛管理中用新题目替换旧题目。注意替换后旧题目的已有提交可能无法关联到新题目需要根据情况决定是否手动重判或给予补偿。这是一个艰难的决定最好在比赛规则中事先说明。网络与电力对于线下赛确保赛场网络有冗余如主备线路评测服务器接入不同断电源UPS。4.4 赛后分析与数据导出比赛结束后工作还没完。DomJudge提供了强大的数据导出功能。导出结果在“Scoreboard”页面可以导出TSV,CSV,JSON,HTML等格式的最终榜单。JSON格式便于进一步处理和分析。导出提交可以导出所有队伍的最终正确代码用于代码查重Plagiarism Detection。DomJudge本身不集成查重功能但导出的代码可以方便地使用JPlag、MOSS等外部工具进行分析。分析题目难度通过统计每道题的提交次数、通过次数、首次通过时间分布等数据可以定量分析题目的难度是否合理为下次出题提供参考。这些数据可以从数据库直接查询或通过DomJudge的API获取。清理与归档一场比赛的数据提交、回执可能会非常庞大。定期清理旧比赛数据或者将其归档到备份存储可以保证生产环境的性能。修改DomJudge的配置文件可以设置自动清理策略。组织一场基于DomJudge的比赛就像导演一部复杂的戏剧。题目配置是打磨剧本和道具比赛管理是调度现场和演员。每一个环节的疏漏都可能被放大。但当你看到榜单上队伍们激烈角逐提交列表不断刷新最终顺利产生冠军时那种成就感也是无与伦比的。希望这篇超过五千字的详细指南能帮你把准备工作做得更扎实让比赛运行得更平稳。记住最宝贵的经验往往来自你亲自踩过的每一个坑所以大胆去实践然后细致地总结吧。