CTF平台实时榜单后端设计：从动态计分到WebSocket推送的完整方案

如果把CTF平台的前端页面做成一把"比赛成绩观测镜"，那么实时榜单就是这面镜子上最容易被高估的一块玻璃。很多第一次接手CTF平台后端的人，第一反应是"榜单不就是查个数据库排个名吗"；等真上了比赛，几十个队伍在最后一小时同时提交、动态分数哗哗往下掉、封榜前一刻排名还在剧烈翻动时，才会意识到这里的水有多深。这篇内容我就以一次真实改造经历为底，完整梳理一份CTF平台实时榜单功能的后端设计方案。它面向的读者是：正准备自研CTF平台、或者已经在维护一套比赛系统、想把榜单从"半小时刷一次"升级成"秒级实时"的后端开发者。

先说结论：实时榜单设计的关键从来不是"推送技术"本身，而是把计分规则、并发正确性、缓存架构、推送时机四条线拧成一根绳。下面我按照实际落地顺序，从业务规则讲到数据模型，再到并发控制、推送通道、缓存优化和封榜结算，每一步都会给出能被直接拿去用的方案和代码骨架。

1. 先把榜单的业务规则掰扯清楚

1.1 CTF榜单到底在排什么

CTF竞赛的核心玩法是：队伍通过解题拿到flag，把flag提交到平台，平台判题系统验证对错。答对了就为队伍增加一道题的分数，榜单按总得分从高到低排列。听起来很简单，但"分数"本身在真实赛事里并不是一成不变的。

最常见的两种计分方式：

• 静态计分：每道题固定一个分值，谁解出来谁拿这个分，简单直观。缺点是强队可以一直压着题不交，最后冲刺时刻集体提交，排名瞬间洗牌，观赏性和公平性都有点问题。
• 动态计分：每道题的分值会随着解出队伍数量增加而衰减，也就是"越多人做出来的题越不值钱"，鼓励队伍优先啃硬骨头。这是目前大多数CTF赛事采用的主流方案。

动态计分给后端带来的第一个麻烦是：同一个队伍的分数不是只增不减的。某道题被更多队伍解出后，它的当前分值会下降，之前已经解出该题的队伍总分会被"回拨"。如果前端和选手不理解这个规则，会直接把平台骂成bug，但后端要明白这是业务预期。

1.2 动态计分的计算公式

我以一个普通赛事平台里常用的衰减模型来举例：

当前分值 = 最低分 + (初始分 - 最低分) / (1 + 解出队伍数 × 衰减系数)

假设某道题初始分500、最低分50、衰减系数0.1：

注意这个公式里"解出队伍数"是动态变化的，所以榜单上已经解出该题的队伍，他们这道题的分值也会被动下降。后端必须在每次有效解出事件发生时，对所有持有该题的队伍做一次分数冲正。

除了动态计分，很多赛事还会设置"一血加成"：某道题第一个解出的队伍额外加分，或者额外展示一个标签。这个相对简单，只要在有效解出记录里标记题目的首次解出者即可。

1.3 封榜、解榜、公示，榜单不是一"刷"到底

正规CTF比赛在临近结束时会有"冻结榜单"阶段。比如比赛4小时，最后1小时榜单冻结：选手前端看到的排名不再变化，防止大家盯着榜单调整策略、导致最后阶段全在"打榜"而不解题。但冻结只是不对外展示，后台的真实排名仍然要实时计算，方便裁判和运营人员盯着局面。

这对后端的影响非常大。它意味着榜单数据层和服务展示层是两回事。数据层必须保持全量、准确、实时更新，展示层才可以在特定时间点选择"不刷新"。这个我在第6部分专门讲。

2. 确立数据模型：从判题回调到榜单记录的链路

2.1 核心表结构怎么设计

实时榜单背后至少要三张核心表，外加一张提交流水表。下面是我经过几轮比赛验证后觉得比较顺的表结构：

CREATE TABLE submissions ( id BIGINT PRIMARY KEY AUTO_INCREMENT, team_id BIGINT NOT NULL, challenge_id BIGINT NOT NULL, status VARCHAR(16) NOT NULL COMMENT 'correct / wrong', submitted_flag TEXT, submitted_at DATETIME NOT NULL, KEY idx_team_challenge (team_id, challenge_id), KEY idx_submitted_at (submitted_at) ); CREATE TABLE solves ( id BIGINT PRIMARY KEY AUTO_INCREMENT, team_id BIGINT NOT NULL, challenge_id BIGINT NOT NULL, solved_at DATETIME NOT NULL, score_snapshot INT NOT NULL COMMENT '解出时该题的当前分值', UNIQUE KEY uk_team_challenge (team_id, challenge_id) ); CREATE TABLE challenges ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(128) NOT NULL, initial_score INT NOT NULL, min_score INT NOT NULL, decay FLOAT NOT NULL DEFAULT 0.1, is_first_blood BOOLEAN DEFAULT FALSE ); CREATE TABLE teams ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL, created_at DATETIME NOT NULL );

几个容易被忽略的设计点：

• submissions是判题系统写入的原始流水，无论正确还是错误都留痕迹，方便赛后审计。
• solves表只记录"第一次正确解出"，并且用(team_id, challenge_id)的唯一索引做硬兜底。这个唯一索引是整个榜单正确性的第一道防线。
• score_snapshot字段保存的是"解出那一刻这道题的当前分值"。这样队伍A在题目分数还是400时解出，队伍B在题目已经衰减到300时才解出，事后回溯分数时不会因为题目分值的后续变化而算错。

2.2 为什么要在Redis里再维护一份榜单

所有比赛数据最终都在数据库里，理论上每次请求实时用SQL算排名也能出结果。但真实赛事里榜单接口的访问频率非常高，尤其比赛尾声，几乎每个选手都开着榜单页面等着刷新。一个实时榜单意味着每秒可能有几十上百次请求，每次都去 count 每个队伍的 solves 并用临时表排序，数据库压力会非常难看。

更关键的是Redis ZSET这个数据结构几乎是为排行榜量身定做的。它用跳表实现，插入和更新的时间复杂度是 O(log N)，取 Top N 的效率极高。所以我的整体设计原则可以概括成一句话：数据库是最终真相，Redis是加速视图。数据库掌管持久化和审计，Redis负责实时排名的计算、读取和推送。

2.3 ZSET里的score怎么维护

假设我们把队伍总分存在一个叫scoreboard:teams的 ZSET 里，score就是队伍当前总分。每道题的有效解出会触发一次总分变更：

1. 先计算该题当前的最新分值。
2. 从队伍总分里扣掉"旧分值"，再加上"新分值"。
3. 如果这是该队伍第一次解出这道题，还要在solves表插入记录。

第一版我直接写Java业务代码逐个执行，后来发现问题很大：并发场景下"读取旧分值、计算新分值、写回"不是原子的。多个判题Worker同时回调，很容易出现覆盖写。正确的做法是把这段逻辑塞进一个Redis Lua脚本里，保证原子性，这部分我会在第3部分详细展开。

这里先给出最基础的Python伪代码，说明ZSET的维护思路：

# 新解出事件：题目challenge_id被队伍team_id解出 # old_value: 该队伍此前从这道题获得的分值（第一次为0） # new_value: 该题当前最新分值 redis.zincrby("scoreboard:teams", -old_value, team_id) redis.zincrby("scoreboard:teams", new_value, team_id) # 同时更新题目的当前分值 redis.zadd("scoreboard:challenges", {challenge_id: new_value})

注意当old_value为0时就是第一次加分，当题目分值因衰减下降时，所有已解出队伍都会被减去差值。这个"批量冲正"也是用同样的ZINCRBY命令，只需要从solves表查出所有解出过该题的队伍ID即可。

3. 并发正确性：这里才是最容易翻车的地方

3.1 判题结果的幂等消费是前提

CTF平台中，前端提交flag后通常不是同步判题，而是放进消息队列，由判题Worker消费。于是你会面对三个并发乱象：

• 同一队伍不同成员几乎同时提交同一道题的flag，判题系统可能连续返回两次"正确"。
• 判题Worker消息重投，同一个正确结果被消费两次。
• 两个不同的判题Worker分别处理不同的题，同时回调，并发更新同一支队伍的分数。

针对前两种情况，solves表的唯一索引已经做了最终兜底：第二次插入会失败，事务回滚，Redis里的积分不会重复增加。针对第三种情况，就需要Lua脚本保证Redis侧的一致性。

3.2 Lua脚本：把"判断+扣旧分+加新分"变成原子操作

下面这段Lua脚本是我在实际项目里用过的骨架，核心思路是：把"是否已解出、旧分扣减、新分累加、解出计数自增"全部放进一个原子上下文执行，任何一步都不会被打断。

-- KEYS[1] : solves:set 集合，记录已解出的 team:challenge -- KEYS[2] : scoreboard:teams 队伍总分ZSET -- KEYS[3] : scoreboard:challenges 题目当前分值ZSET -- KEYS[4] : challenge:solve_count 题目解出数计数器 -- ARGV[1] : team_id -- ARGV[2] : challenge_id -- ARGV[3] : challenge_key 如 "ch:3" -- ARGV[4] : team_key 如 "team:12" -- ARGV[5] : 新分值（应用层先按预计的当前解出数算出，也可在脚本内算） local member = ARGV[1] .. ":" .. ARGV[2] local exists = redis.call("SISMEMBER", KEYS[1], member) if exists == 1 then return 0 end redis.call("SADD", KEYS[1], member) local old_val = tonumber(redis.call("ZSCORE", KEYS[3], ARGV[3]) or 0) if old_val > 0 then redis.call("ZINCRBY", KEYS[2], -old_val, ARGV[4]) end -- 更新该题当前分值 redis.call("ZADD", KEYS[3], ARGV[5], ARGV[3]) redis.call("ZINCRBY", KEYS[2], ARGV[5], ARGV[4]) -- 解出数自增，供后续动态计分使用 redis.call("INCR", KEYS[4]) return 1

使用Redis Cluster环境时，要确保脚本里所有key都带相同的hash tag（例如统一加{scoreboard}前缀），否则会报跨slot错误。这块别偷懒，线上踩过坑就会知道多疼。

3.3 数据库事务与Redis缓存的一致性问题

一个经典问题是：solves表插入和Redis积分更新，谁先谁后？

我的做法比较朴素：先提交数据库事务，插入solves记录；事务成功后再执行Redis更新。因为数据库是最终真相，Redis只是可重建的加速层。如果Redis更新失败，会有一个周期性的补偿任务，扫描最近一分钟内有solves插入但Redis榜单版本未递增的异常数据，重新补算对应队伍的分数。这里不追求数据库和Redis的强一致，只要求最终一致，因为比赛期间偶尔一次榜单延迟刷新，远比数据错乱容易接受。

另外强调一点：别让数据库事务去包Redis操作。数据库分布式事务和Redis事务是两套独立体系，硬包在一起只会把判题回调响应时间拉长，还容易死锁。

3.4 手动重算与脏数据处理

动态计分带来的另一个麻烦是：如果某道题的衰减参数配置错了，或者某条被判为违规的队伍要被扣分，整个榜单需要批量调整。我的建议是维护一个"重建脚本"，可以从solves表全量重建Redis榜单。实现思路很简单：

• 清空队伍总分ZSET、题目分值ZSET、解出数计数器。
• 按solved_at顺序扫描所有solves记录。
• 每扫描一条，对题目解出计数自增，重新计算该题当前分值，再把这支队伍的score_snapshot的差量累加到总分ZSET。

这个重建脚本平时不跑，但在出故障时、比赛结束后做最终名次核验时非常有用。

4. 从Redis到浏览器：实时推送通道设计

4.1 先选型：轮询、SSE还是WebSocket

我把三个方案放在一起对比过，各有适用场景：

实际项目中我最终选了WebSocket。原因有两个：第一，CTF平台前端除了榜单，通常还要实时接收"提交判题结果"，这一个通道可以两件事一起做；第二，WebSocket在浏览器和后端都有成熟生态，踩坑成本可控。

4.2 榜单更新事件的分发拓扑

假设榜单服务部署了两台节点，所有WebSocket连接分别挂在两台节点上。现在一台判题Worker完成了有效解出，Redis榜单积分已经更新，但挂载在另一台节点上的浏览器还不知情。怎么把变更广播到所有连接？

我采用的方案是用Redis Pub/Sub做事件总线：

• 榜单更新时，发布一条消息到scoreboard:changed频道。
• 每台榜单服务节点都订阅同一个频道，收到消息后在自己的连接管理器里向本机WebSocket连接群发。
• 前端收到消息后，决定是全量刷新榜单还是应用增量补丁。

文字流程是：

判题Worker写入数据库 -> 更新Redis ZSET -> 发布 Redis Pub/Sub 事件 -> 所有榜单服务节点订阅并收到事件 -> 各节点向本机WebSocket客户端广播 -> 浏览器更新榜单视图

单个事件重复广播到多个节点确实存在消息冗余，但CTF比赛的提交频率其实不算高，这种量级的广播完全够用。Redis Pub/Sub本身不持久化，消息丢了就丢了，所以还要搭配一个"全局版本号"机制，我放在4.3里说。

4.3 推送里带什么：全量快照还是增量事件

刚开始我图简单，每次榜单变更都把Top 50完整列表推给所有客户端。参赛队伍几百支时问题不大，但很快就发现比赛接近尾声时，一次错题提交也会触发无意义的全量推送，前端渲染压力大，带宽也浪费。

后来改成增量事件，只推送变化本身：

{ "type": "scoreboard:update", "version": 1024, "payload": { "team_id": 12, "challenge_id": 3, "challenge_title": "web-easy", "score_delta": -75, "rank": 7 } }

前端在本地维护一份榜单快照，收到增量事件后自行更新分数和排名。这个方案的缺点是断线重连后可能错过中间事件，所以每次连接建立和重连时，客户端要带自己当前的version上来；服务端比对全局版本号，不一致就返回一个scoreboard:reset事件，强制客户端全量拉取一次榜单。有版本号兜底，增量推送即使偶尔丢消息也能自愈。

4.4 心跳与连接上限

WebSocket长连接最怕"死连接占坑"。客户端断网时服务端不会立刻感知，TCP层可能要等很久才能发现。我统一的处理是：服务端每30秒发送一次ping，客户端在收到ping或主动事件后返回pong，连续两次pong超时就关闭连接并清理连接管理器里的会话。

连接上限也要提前设计。我一般会做两个保护：每台节点设置最大连接数，超过之后拒绝新连接但允许前端退化为轮询模式；同时给WebSocket连接按IP做速率限制，防止有人刷连接打爆节点资源。

5. 榜单接口的读取性能与缓存架构

5.1 查询路径的分层缓存

实时推送解决的是"服务端主动把变化告诉浏览器"，但在增量事件触发全量刷新、前端重新拉榜单接口时，接口本身的压力也要控制。我做了两级缓存：

• 本地进程缓存：榜单JSON快照放在服务节点内存里，TTL设为3秒。同一节点内多个请求直接命中内存，不碰Redis。
• Redis分布式缓存：如果服务节点是多个，本地缓存命中率会下降，此时从Redis里读榜单快照字符串，TTL同样很短。

这里有个技巧：Redis里榜单快照的key可以命名为scoreboard:snapshot:{version}，版本号作为key的一部分。每次榜单变更，版本号递增，新请求读新key，旧key自然过期。这样避免了"缓存失效"操作——每次更新都是写新数据，天然无锁。

5.2 Top N快照与分页

榜单首页通常只展示Top 20或Top 50，这个从ZSET取非常快：

ZREVRANGE scoreboard:teams 0 49 WITHSCORES

如果要支持完整榜单的分页查看，我用的是ZREVRANGE按偏移量取，同时在每个页码的key后面拼版本号做页缓存。因为CTF参赛队伍一般几百到几千，哪怕全量榜单分页扫描，单指令耗时也在毫秒级，瓶颈主要还是WebSocket广播和前端渲染。

5.3 不同赛事规模的选型参考

我在设计时通常按规模分三档：

| 参赛队伍规模 | 推荐方案 | |---|---:|---| | 50队以内 | 轮询即可，3秒一次，后端直接查Redis | | 50~500队 | WebSocket + 增量推送，ZSET排行，单节点足够 | | 500队以上 | 多节点部署 + Redis Pub/Sub广播 + 页缓存 + 连接限流 |

500队以上时要特别注意"重连风暴"：比赛进入最后阶段，选手反复切页面会导致WebSocket重连。每次重连都做全量榜单拉取，会瞬间打爆数据库。我的兜底方案是：全量刷新的响应里带version和next_pull_after字段，客户端在重连高峰期至少要等3秒才能再次拉取。

5.4 冷启动时的榜单重建

比赛开场前，所有WebSocket连接还没建立，但已经有队伍开始提交，Redis榜单会持续更新。此时如果某个服务节点重启，或者Redis因为运维操作被清了内存，就需要从数据库快速重建榜单。

我的做法是：每个节点启动时先检查scoreboard:teams这个ZSET是否存在且版本号大于0，如果不存在，就拉一次全量重建任务。重建任务在后台执行，执行完成前，前端接口返回"榜单构建中"的状态，而不是直接报错。重建完成后，通过scoreboard:reset事件通知所有已连接客户端刷新。

6. 封榜与结算：比赛结束时的最后一道坎

6.1 封榜的技术实现

很多第一次做封榜的人会把冻结做在"数据更新层"，即封榜后Redis ZSET不再更新。这是不对的。封榜期间判题系统还在工作，后台裁判需要看到真实排名，而且解榜瞬间如果才突然重算，很容易出现大量数据同时变动的高峰。

正确做法是把冻结做在展示层：

• Redis数据层继续实时更新。
• 排行榜事件发布器在freeze_ts之后不再向WebSocket客户端广播增量事件。
• 后台管理端走独立接口读取真实榜单，不受冻结影响。
• 解冻时向所有客户端广播一次scoreboard:unfreeze事件，客户端收到后强制全量拉取，一次性把最后阶段的排名变动展示出来。

这个方案的好处是解冻时只有一次全量刷新压力，而不会出现"数据层堆积了1小时未处理变更、解冻时集中爆炸"的情况。

6.2 提交时间的切断

比赛结束瞬间，判题队列里可能还有一堆正在处理的提交，其中一部分是在截止时间之后才被Worker消费的。这些提交绝不能影响最终榜单。我的处理原则是：以submitted_at落库时间为准。判题回调写入solves表之前，先判断提交时间是否已超过end_at；超过则只写submissions流水和状态为expired，不触发积分逻辑。

封榜和结算阶段也一样，只认提交时间，不认回调到达时间。这个看似简单，实际操作中很容易因为消息队列重试导致时间判断错误，所以判题结果事件里必须携带原始的submitted_at字段，而不是用消费者本地时间。

6.3 赛后最终榜单落库

比赛结束后，解冻榜单，运行最终重算脚本，把所有队伍的最终分数、最终排名固化到一张持久化表里，比如scoreboard_final。之后如果裁判委员会判定某支队伍违规、需要扣分，直接在数据库层面修改solves记录并重跑重算脚本，重新生成最终榜单，所有历史页面展示以这张表为准。

这个阶段千万别再依赖Redis里的实时榜单，因为它只是为了比赛过程中的秒级展示而存在，赛后核验必须回到数据库的最终真相。

6.4 实战踩坑清单

最后把我这几年在CTF平台榜单上踩过的坑集中列一下：

说完这些，我的习惯是补一句真心话：实时榜单不是一个可以一次性设计到位的模块，它更像一套积木，先把"正确"搭出来，再考虑"实时"，最后考虑"高并发"。千万别一开始就上很重的架构，几百人的比赛用上微服务加消息队列，只会让自己在比赛前夜失眠。每次想到比赛最后五分钟，选手们盯着榜单眼睛发红的样子，你就会明白，后端设计里那些看似不起眼的细节——幂等、时间切断、封榜、版本号——才是让这场比赛真正体面收场的底气。