C++构建高并发在线判题系统：负载均衡与容器化实战-尧图网络科技

1. 项目概述：一个能处理海量代码提交的在线判题系统

最近在社区里看到不少朋友在讨论如何构建一个自己的在线判题系统（Online Judge，简称OJ），尤其是用C++来写后端。这让我想起了几年前和团队一起折腾的一个项目，目标不仅仅是实现一个能跑通代码的OJ，而是要做一个能应对高并发、稳定可靠的负载均衡式在线OJ。简单来说，就是当有成百上千个用户同时提交代码进行编译运行判题时，系统不能卡死或崩溃，得能“扛得住”。

这个项目的核心价值在于，它把一个经典的C++网络服务开发场景，从单机玩具级别提升到了接近生产环境的复杂度。你不仅会用到C++进行核心业务逻辑（编译、运行、判题）的开发，还会涉及到多进程/多线程并发模型、网络通信、负载均衡策略、容器化部署等一系列后端工程师的必备技能。对于想深入C++服务端开发、或者对系统设计感兴趣的朋友来说，这是一个绝佳的练手项目。它能帮你把书本上的TCP/IP、进程间通信（IPC）、同步互斥等知识，串联成一个有血有肉、可运行、可观测的真实系统。

效果上，我们最终实现了一个支持多语言（C/C++/Python/Java等）的判题平台。前端用户提交代码后，后端会动态地将判题任务分发给多个判题机（Worker），这些Worker可能运行在不同的容器或物理机上，由负载均衡器（我们选用Nginx）统一调度。整个流程从用户提交到返回结果，包括编译、运行、对比输出，都能在秒级完成，并且通过监控可以看到，当单个Worker压力过大时，新的任务会被自动调度到空闲的Worker上，系统吞吐量得到显著提升。接下来，我就把这个项目的设计思路、关键实现以及踩过的坑，详细地拆解一遍。

2. 项目整体设计与核心思路拆解

2.1 为什么需要负载均衡？

一个最基础的OJ，架构可能很简单：一个Web服务器接收提交，后端一个判题进程挨个处理。当同时来10个提交时，第10个用户可能得等前面9个都编译运行完才能开始，体验极差。更糟糕的是，如果某个提交的代码陷入死循环，这个判题进程就会被卡住，后续所有提交都瘫痪了。

负载均衡就是为了解决这个问题。它的核心思想是“分工”和“调度”。我们启动多个判题服务实例（称为判题机或Worker），然后引入一个“调度员”（负载均衡器）。所有用户的代码提交请求先发给调度员，由它根据一定策略（比如看哪个Worker最闲），把任务分发给具体的Worker去执行。这样，多个任务可以并行处理，系统处理能力（吞吐量）成倍增加；同时，单个Worker的故障（比如被恶意代码搞崩溃）不会导致整个服务不可用，其他Worker还能继续工作，系统的可用性和可靠性都增强了。

在我们的项目中，这个“调度员”的角色由Nginx担当。Nginx本身是一个高性能的HTTP和反向代理服务器，其负载均衡模块非常成熟稳定。判题机Worker则是我们用C++编写的独立网络服务。

2.2 系统架构总览

整个系统可以划分为三大模块：前端Web服务、负载均衡与路由层、判题机集群。它们之间通过HTTP/HTTPS协议进行通信，松耦合，便于独立开发和部署。

前端Web服务：负责用户交互界面。用户在这里注册、登录、浏览题目、编写并提交代码。它不负责判题，只负责收集代码和题目ID，然后打包成一个判题请求（JSON格式），发送给负载均衡器。这个部分可以用任何你熟悉的技术栈实现，比如Vue.js+Node.js，或者传统的PHP、Java等。它的核心职责是“展示”和“收集”。
负载均衡与路由层（Nginx）：这是系统的交通枢纽。它暴露一个对外的API接口（例如/judge）。前端将所有判题请求发到这个接口。Nginx内部配置了一个upstream，里面列出了所有判题机Worker的地址和端口。当请求到来时，Nginx按照预设的策略（如轮询、最少连接数），将请求转发给某一个Worker。此外，这一层还负责SSL/TLS终止（即HTTPS解密），让后端的Worker可以专注于HTTP明文业务逻辑，提升安全性和性能。
判题机集群（C++ Worker）：这是系统的核心引擎，也是我们用C++主要实现的部分。每个Worker是一个独立的进程，它需要完成以下核心工作：
- 接收任务：从Nginx接收判题请求（JSON）。
- 资源隔离与安全运行：这是OJ最难也最关键的部分。绝不能直接在宿主服务器上编译运行用户提交的未知代码。我们必须为每次判题创建一个隔离的“沙盒”环境。这里我们使用Linux Namespace和Cgroups技术。Namespace（如pid,mount,net等）用于隔离进程的视图，让运行中的程序以为自己在一个独立的系统里；Cgroups用于限制资源（CPU时间、内存大小）。通过这两者，我们可以限制用户程序最多使用多少内存、运行多长时间，防止恶意代码耗尽系统资源。
- 编译：根据请求中的语言类型，调用相应的编译器（g++/gcc for C/C++, javac for Java, python本身是解释型可跳过编译）。编译过程也在受控的环境中进行。
- 运行与判题：运行编译好的程序（或解释器执行脚本），将题目的标准输入（stdin）喂给程序，捕获程序的输出（stdout）、错误输出（stderr）和退出码。然后将用户输出与题目的标准输出进行对比（通常采用逐行对比或忽略空格对比）。
- 返回结果：将判题结果（如Accepted,Wrong Answer,Time Limit Exceeded,Memory Limit Exceeded,Compile Error等）封装成JSON，返回给Nginx，再经由Nginx返回给前端。

整个数据流是：用户浏览器 -> 前端服务器 -> Nginx -> 某个C++ Worker -> (沙盒内编译运行) -> C++ Worker -> Nginx -> 前端服务器 -> 用户浏览器。

2.3 技术选型背后的考量

C++用于编写Worker：判题过程涉及频繁的进程创建、文件操作、网络I/O和字符串处理，对性能要求极高。C++在性能和控制力上具有天然优势，能精细地管理内存和系统调用，非常适合实现沙盒和判题逻辑。虽然用Go或Java也能实现，但C++能让我们更贴近系统底层，理解整个控制流程。
Nginx作为负载均衡器：它轻量、高性能、高并发，负载均衡算法丰富，配置灵活。相比于自己用C++写一个负载均衡器，使用Nginx是更稳定、更专业的选择，让我们能专注于核心业务逻辑。同时，它的反向代理功能完美契合了我们的架构。
Docker（可选但推荐）用于环境标准化：虽然Worker内部用Namespace和Cgroups做隔离，但Worker本身的运行环境（依赖的库、编译器版本）也需要一致。使用Docker容器来封装每个Worker，可以确保集群内所有判题机环境完全一致，避免“在我机器上能跑”的问题。这也是热词中“用docker做多个后端java web容器”思路的C++版实践。
JSON作为通信协议：结构清晰，易于阅读和调试，各种语言都有成熟的解析库（如C++的nlohmann/json）。虽然二进制协议（如Protobuf）性能更高，但在本项目的数据量和复杂度下，JSON的开发效率优势更大。

3. 核心模块详解与C++实现要点

3.1 判题机Worker的核心结构

一个Worker本质上是一个HTTP服务器。我们可以使用httplib（一个轻量级C++单头文件HTTP库）来快速搭建，也可以使用更底层的libevent或Boost.Asio来自主控制。为了简化，这里以httplib为例描述主体结构。

// 伪代码，展示核心逻辑 #include “httplib.h” #include “nlohmann/json.hpp” #include “judge_core.h” // 核心判题逻辑模块 int main() { httplib::Server svr; // 定义判题接口 svr.Post(“/judge”, [](const httplib::Request& req, httplib::Response& res) { // 1. 解析请求JSON nlohmann::json request_json = nlohmann::json::parse(req.body); int problem_id = request_json[“problem_id”]; std::string code = request_json[“code”]; std::string language = request_json[“language”]; // 2. 调用核心判题函数（这是一个耗时操作） nlohmann::json result_json = JudgeCore::judge(problem_id, code, language); // 3. 返回结果JSON res.set_content(result_json.dump(), “application/json”); }); // 健康检查接口，供Nginx或监控系统调用 svr.Get(“/health”, [](const httplib::Request& req, httplib::Response& res) { res.set_content(“OK”, “text/plain”); }); svr.listen(“0.0.0.0”, 8080); // Worker监听端口 return 0; }

注意：在实际生产中，/judge接口的处理函数必须是非阻塞的，或者使用多线程。因为判题过程可能长达数秒，如果单线程阻塞处理，这个Worker同时只能处理一个请求，负载均衡就失去了意义。通常我们会引入一个任务队列和线程池，主线程快速接收请求放入队列，工作线程从队列取出任务执行判题。这是实现高并发的关键。

3.2 沙盒环境构建：Namespace与Cgroups实战

这是C++ Worker中最具挑战性的部分。我们需要在代码中调用Linux系统API来创建隔离环境。

步骤简述：

准备代码和输入文件：在临时目录（如/tmp/oj_xxxx）中，写入用户提交的源代码和题目的输入文件。
创建子进程：使用fork()系统调用。
在子进程中设置隔离（在exec()运行用户程序之前）：
- 调用unshare()系统调用：传入CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET | CLONE_NEWIPC等标志，创建新的Namespace。这样，子进程及其后续创建的所有进程将拥有独立的PID、挂载点、网络和IPC空间。
- 调用chroot()（可选但更安全）：将根目录切换到临时目录下的一个安全子目录，进一步限制文件系统访问。这需要root权限或CAP_SYS_CHROOT能力。
- 设置Cgroups：将子进程的PID写入对应的Cgroup任务文件（如/sys/fs/cgroup/memory/oj_group/tasks），以限制其内存使用。同时，通过写入memory.limit_in_bytes和cpu.cfs_quota_us等文件来设定内存和CPU限制。
- 设置资源限制setrlimit()：这是另一道防线，用于限制进程能创建的最大文件大小、栈大小等。
- 切换用户身份setuid()/setgid()：切换到一個低权限的普通用户（如nobody）来运行用户程序，这是最重要的安全措施之一，防止提权。
在子进程中exec()用户程序（或编译器）。
在父进程中监控子进程：使用waitpid()或poll/select监控子进程状态，同时启动定时器。如果子进程运行超时（根据题目时间限制），父进程则通过Cgroups或发送SIGKILL信号强制终止它。

// 伪代码，展示核心步骤 pid_t pid = fork(); if (pid == 0) { // 子进程 // 设置新的Mount Namespace，并挂载一个干净的proc unshare(CLONE_NEWNS); mount(“none”, “/proc”, “proc”, 0, NULL); // 设置Cgroup内存限制为64MB std::string cgroup_path = “/sys/fs/cgroup/memory/oj_” + std::to_string(getpid()); mkdir(cgroup_path.c_str(), 0755); write_to_file(cgroup_path + “/memory.limit_in_bytes”, “67108864”); // 64MB write_to_file(cgroup_path + “/tasks”, std::to_string(getpid())); // 切换到一个低权限用户（假设uid=1001的用户ojrunner存在） setuid(1001); setgid(1001); // 限制进程自身资源（RLIMIT_AS限制地址空间，约等于内存） struct rlimit rl; rl.rlim_cur = rl.rlim_max = 64 * 1024 * 1024; // 64MB setrlimit(RLIMIT_AS, &rl); // 重定向标准输入输出到准备好的文件 freopen(“input.txt”, “r”, stdin); freopen(“output.txt”, “w”, stdout); freopen(“error.txt”, “w”, stderr); // 执行用户程序 execl(“./user_program”, “./user_program”, (char*)NULL); exit(1); // execl失败才执行到这里 } else { // 父进程 // 设置超时（例如2秒） int status; struct timespec start, now; clock_gettime(CLOCK_MONOTONIC, &start); bool timeout = false; while (true) { int ret = waitpid(pid, &status, WNOHANG); if (ret == pid) { // 子进程已结束 break; } clock_gettime(CLOCK_MONOTONIC, &now); if ((now.tv_sec - start.tv_sec) > 2) { // 超时2秒 kill(pid, SIGKILL); // 强制杀死 timeout = true; waitpid(pid, &status, 0); // 回收僵尸进程 break; } usleep(10000); // 休眠10ms再检查 } // 收集输出文件内容，判断结果... }

实操心得：沙盒的实现极其复杂且容易出错。一个常见的坑是权限问题。创建Namespace、挂载文件系统、设置Cgroup通常需要root权限。但我们的Worker进程又不能一直以root运行，否则一旦沙盒逃逸，整个服务器就沦陷了。常见的做法是：
赋予Worker二进制文件特定的Linux能力（Capabilities），例如CAP_SYS_ADMIN,CAP_SYS_CHROOT,CAP_DAC_OVERRIDE等，使用setcap命令。这样Worker可以以非root用户身份执行这些特权操作。
或者，启动一个高权限的“守护进程”来专门负责创建沙盒，Worker通过进程间通信（如Unix Domain Socket）向其发起请求。这种方式更安全，但架构更复杂。强烈建议在实现沙盒前，先深入研究Linux的权限模型（root, capabilities, setuid）和容器安全。

3.3 负载均衡器Nginx配置详解

Nginx的配置是连接前端和Worker的桥梁。一个基本的负载均衡配置如下：

http { # 定义上游服务器组，即我们的C++ Worker集群 upstream oj_backend { # 负载均衡策略，least_conn表示将请求发给当前连接数最少的服务器 least_conn; # 定义Worker服务器，可以配置多台，这里用本机不同端口模拟 server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; server 127.0.0.1:8081 max_fails=3 fail_timeout=30s; server 127.0.0.1:8082 max_fails=3 fail_timeout=30s; # 可以配置权重（weight），性能好的机器权重高 } server { listen 80; server_name oj.yourdomain.com; # 你的域名 # 可选：重定向到HTTPS # return 301 https://$server_name$request_uri; location /judge { # 将/judge路径的请求代理到上游服务器组 proxy_pass http://oj_backend; # 以下是一些重要的代理设置 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 设置超时，判题可能较慢 proxy_read_timeout 60s; proxy_connect_timeout 15s; proxy_send_timeout 15s; } location /health { # 健康检查端点，可以配置Nginx主动检查或供外部监控 proxy_pass http://oj_backend; } } }

关键配置解析：

max_fails=3 fail_timeout=30s：这是健康检查的关键。如果Nginx连续3次请求某个Worker失败，会在接下来的30秒内将其标记为“不可用”，不再向其转发流量。这提高了系统的容错能力。我们的Worker需要实现/health接口并快速返回。
least_conn：负载均衡策略。我们选择“最少连接数”，这比简单的“轮询”（默认）更智能，能更好地将请求分配给当前压力小的Worker。其他策略还有ip_hash（同一IP固定到某Worker，适合有状态服务，但OJ无状态）等。
proxy_read_timeout 60s：判题过程可能较长，需要调大超时时间，避免请求在传输过程中被Nginx断开。

3.4 使用Docker容器化部署Worker

为了环境一致性和便捷伸缩，将每个C++ Worker打包成Docker镜像是最佳实践。

Dockerfile示例：

# 使用一个包含编译和运行环境的轻量级基础镜像 FROM ubuntu:22.04 # 安装系统依赖和编译器 RUN apt-get update && apt-get install -y \ g++ \ gcc \ python3 \ openjdk-17-jdk-headless \ # 其他语言编译器... libseccomp-dev \ # 用于更精细的沙盒控制（如seccomp-bpf） cmake \ make \ && rm -rf /var/lib/apt/lists/* # 创建一个低权限用户用于运行程序 RUN useradd -m -s /bin/bash ojrunner # 设置工作目录 WORKDIR /app # 将编译好的Worker可执行文件复制到镜像中 COPY ./oj_worker . # 暴露端口（与Worker代码中监听端口一致） EXPOSE 8080 # 以非root用户启动容器（增强安全性） USER ojrunner # 启动Worker服务 CMD [“./oj_worker”]

编排与运行：使用docker-compose可以轻松启动一个Worker集群。

# docker-compose.yml version: ‘3.8’ services: oj-worker-1: build: . container_name: oj-worker-1 ports: - “8080:8080” # 主机端口映射，实际生产环境可能用内部网络 networks: - oj-network # 可以配置资源限制，与Cgroups配合 deploy: resources: limits: cpus: ‘1’ memory: 512M oj-worker-2: build: . container_name: oj-worker-2 ports: - “8081:8080” networks: - oj-network deploy: resources: limits: cpus: ‘1’ memory: 512M # 可以定义更多worker... nginx: image: nginx:alpine container_name: oj-loadbalancer ports: - “80:80” - “443:443” # 如果配置了HTTPS volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro # 挂载自定义的Nginx配置 - ./ssl_certs:/etc/nginx/ssl:ro # 挂载SSL证书（如需HTTPS） networks: - oj-network depends_on: - oj-worker-1 - oj-worker-2 networks: oj-network: driver: bridge

这样，一条docker-compose up -d --scale oj-worker=5命令就能快速拉起一个包含5个Worker实例和1个Nginx的完整集群。

4. 开发环境搭建与调试技巧

4.1 VSCode配置C++开发环境

对于这样一个中型C++项目，一个好的IDE至关重要。VSCode配合插件是绝佳选择。

安装必备插件：
- C/C++ (Microsoft)：提供IntelliSense、调试、代码浏览等功能。
- CMake Tools：如果你的项目使用CMake构建（推荐），这个插件能极大简化配置。
- Code Runner：快速运行单个文件。

配置c_cpp_properties.json：这个文件告诉VSCode的C++插件在哪里找头文件、使用哪个编译器标准等。

{ “configurations”: [ { “name”: “Linux”, “includePath”: [ “${workspaceFolder}/**”, “/usr/include”, “/usr/local/include” // 添加第三方库路径，如jsoncpp ], “defines”: [], “compilerPath”: “/usr/bin/g++”, “cStandard”: “c17”, “cppStandard”: “c++17”, “intelliSenseMode”: “linux-gcc-x64” } ], “version”: 4 }

配置tasks.json用于构建：定义如何编译你的项目。

{ “version”: “2.0.0”, “tasks”: [ { “label”: “build OJ Worker”, “type”: “shell”, “command”: “g++”, “args”: [ “-std=c++17”, “-g”, // 生成调试信息 “-pthread”, // 链接线程库 “-lhttplib”, // 链接httplib，假设是系统库 “-ljsoncpp”, // 链接json库 “${workspaceFolder}/src/*.cpp”, “-o”, “${workspaceFolder}/bin/oj_worker” ], “group”: { “kind”: “build”, “isDefault”: true }, “problemMatcher”: [“$gcc”] } ] }

配置launch.json用于调试：这是调试沙盒逻辑的关键。你需要配置调试器（如GDB）来附加到你的程序。

{ “version”: “0.2.0”, “configurations”: [ { “name”: “(gdb) Launch OJ Worker”, “type”: “cppdbg”, “request”: “launch”, “program”: “${workspaceFolder}/bin/oj_worker”, “args”: [], “stopAtEntry”: false, “cwd”: “${workspaceFolder}”, “environment”: [], “externalConsole”: false, “MIMode”: “gdb”, “setupCommands”: [ { “description”: “为 gdb 启用整齐打印”, “text”: “-enable-pretty-printing”, “ignoreFailures”: true } ], “preLaunchTask”: “build OJ Worker” // 调试前先构建 } ] }

4.2 调试沙盒和多进程的实用技巧

调试涉及fork()和exec()的多进程程序比较棘手。以下是一些实用方法：

使用ptrace和GDB：GDB默认会跟踪父进程。在子进程调用exec()之后，你可以通过set follow-fork-mode child命令让GDB跟踪子进程。在VSCode的launch.json中，可以添加"setupCommands": [{"text": "set follow-fork-mode child"}]。
大量使用日志：在关键节点（如fork()后、设置Namespace前、exec()前、收到信号后）打印详细的日志到文件或标准错误。这是定位问题最直接的手段。可以设计一个简单的日志宏。
```
#define LOG(level, fmt, …) fprintf(stderr, “[%s] “ fmt “\n”, #level, ##__VA_ARGS__) // 使用 LOG(INFO, “Forked child pid: %d”, pid);
```
分阶段测试：不要试图一次性写完所有沙盒功能。
1. 先实现一个能编译运行固定代码的版本。
2. 再加入超时控制。
3. 然后加入内存限制（Cgroups）。
4. 最后再加入Namespace隔离和权限降级。每完成一步都充分测试。
使用strace/ltrace：这两个工具能跟踪进程的系统调用和库函数调用。当程序行为异常时，用strace -f -p <pid>跟踪父子进程的所有系统调用，能清晰看到权限错误、文件访问失败等问题。

5. 常见问题排查与性能优化实录

在开发和运维这个系统的过程中，我们遇到了不少典型问题。这里记录下排查思路和解决方案。

5.1 判题结果不一致或随机错误

现象：同一份代码，多次提交有时Accepted，有时Wrong Answer或Runtime Error。
排查：
1. 检查文件描述符未关闭：在父进程中，fork()之后，子进程会继承所有打开的文件描述符。如果在父进程中打开了文件（如日志文件、socket）但没有设置FD_CLOEXEC标志，子进程exec()后这些描述符依然存在，可能导致资源泄露或意想不到的I/O干扰。确保在fork()后，子进程关闭所有不需要的描述符。
2. 检查临时目录竞争：如果多个判题任务共用同一个临时目录名，可能会发生文件读写冲突。确保每次判题为子进程生成一个全局唯一的临时目录（如使用mkdtemp函数）。
3. 检查信号处理：子进程可能意外继承了父进程的信号处理函数。在exec()之前，应将子进程的信号处理重置为默认（SIG_DFL）或忽略（SIG_IGN），特别是SIGPIPE。
4. 检查内存泄漏：Worker进程长时间运行后，如果存在内存泄漏，可能导致后续判题时内存不足，行为异常。使用Valgrind等工具检测Worker程序本身的内存问题。

5.2 Worker进程无故退出或被Nginx标记为失败

现象：Nginx日志中出现502 Bad Gateway或upstream timed out，upstream列表中的Worker被临时移除。
排查：
1. 检查健康检查接口：确保Worker的/health接口响应迅速（例如只检查自身状态，不进行复杂操作），并且返回正确的HTTP状态码（如200）。
2. 检查资源限制：Worker进程本身可能被宿主机的Cgroups或系统资源限制（如ulimit -n文件描述符数）卡住。使用dmesg查看内核日志，看是否有OOM killer杀死了Worker。
3. 检查沙盒逃逸或死锁：用户提交的恶意代码可能试图攻击沙盒，导致Worker进程崩溃。加强沙盒安全（如使用seccomp-bpf过滤系统调用）。另外，父进程等待子进程时如果发生死锁，也会导致Worker线程卡死，无法响应请求。确保超时逻辑正确，并使用SIGKILL这种不可捕获的信号来终止失控的子进程。
4. 调整Nginx超时参数：如果判题确实需要较长时间（如Java程序启动慢），适当增加Nginx的proxy_read_timeout和Worker的健康检查超时。

5.3 系统吞吐量上不去

现象：增加了Worker数量，但整体QPS（每秒查询率）没有线性增长。
排查与优化：
1. 数据库/文件系统瓶颈：如果所有Worker都读写同一个数据库或同一个网络存储（NFS）上的题目测试用例，I/O可能成为瓶颈。考虑使用内存缓存（如Redis）缓存题目数据，或者将测试用例文件分布式存储在每个Worker本地。
2. 锁竞争：Worker内部如果使用了全局锁（例如一个全局的日志锁、任务队列锁），在高并发下会严重限制性能。尽量使用线程本地存储（TLS）或无锁数据结构。
3. Worker配置不当：每个Worker配置的线程数或进程数需要优化。并不是线程越多越好，过多的线程会导致上下文切换开销增大。可以通过压测工具（如wrk,ab）找到最佳线程数。公式参考：线程数 ≈ CPU核心数 * (1 + 等待时间/计算时间)。对于判题这种I/O密集型（等待编译、运行）任务，可以配置较多线程。
4. Nginx负载均衡策略：默认的轮询策略可能不均衡，如果每个判题任务耗时差异大，会导致有的Worker忙死，有的闲死。切换到least_conn（最少连接数）策略通常效果更好。
5. 内核参数优化：调整Linux系统的网络参数，如增加net.core.somaxconn（监听队列长度）、net.ipv4.tcp_tw_reuse（TIME_WAIT套接字重用）等，可以提升网络性能。

5.4 安全加固要点

非Root运行：这是铁律。Worker进程、容器都必须以非root用户运行。
Seccomp-BPF：在Namespace和Cgroups之外，使用Seccomp-BPF来限制子进程可以调用的系统调用。例如，判题程序通常不需要mount,ptrace,socket等系统调用。可以编写一个严格的seccomp配置文件，在子进程中加载。
能力（Capabilities）最小化：如果Worker需要某些特权，只赋予其最小必要的能力集，而不是CAP_SYS_ADMIN这种“超级能力”。
定期更新与漏洞扫描：保持编译器、系统库、Docker镜像的基础版本更新，定期对容器进行安全扫描。

这个负载均衡式在线OJ项目，从设计到实现，几乎涵盖了C++服务端开发中除了数据库设计外的所有核心难点：网络编程、多线程并发、进程管理、系统调用、资源控制、安全隔离、负载均衡、容器化。把它吃透，你对Linux系统编程和分布式系统设计的理解会上一个大台阶。在实际编码中，最花时间的往往不是主体逻辑，而是这些边界条件的处理和调试。多写日志，分模块测试，善用调试工具，是搞定这类复杂系统的不二法门。