办电竞比赛的人大概都有过这种经历报名靠群接龙队伍信息散落在 Excel 里赛程是手绘树状图比分靠比赛截图对账。无畏契约这种 5v5 的战术竞技游戏组织一场像样的赛事远比想象中繁琐。这篇文章我来讲一讲基于 Spring Boot 的赛事平台怎么做从需求拆解到数据库设计再到核心接口、实时推送和权限控制把一条可落地的实现路线完整铺开。如果你正想给社团、社群或公司内部做一套赛事管理系统这篇文章可以作为直接参考。1. 赛事平台的需求拆解办一场比赛到底需要哪些功能很多开发者拿到这类题目第一反应是做个 CRUD 后台不就行了但真正上手会发现赛事平台的复杂度集中在状态流转和角色协作上而不是增删改查。1.1 一场无畏契约赛事从创建到结束的完整流程无畏契约是 5v5 模式常规赛事还带替补所以一场比赛的组织链路大概是这样的主办方创建赛事填写比赛项目、报名截止时间、比赛开始时间、队伍数量上限、赛制BO1、BO3、双败淘汰还是小组单循环然后发布公告。队伍队长在报名窗口内提交队伍信息包括队名、队员的玩家 ID、游戏内段位截图等材料。报名截止后主办方或运营人员逐条审核报名记录通过的队伍进入赛程池。接下来系统根据赛制自动生成对阵图或者由人工手动排定初赛分组。比赛日当天裁判为每场对局创建比赛房间记录地图 BP 结果比赛双方对局结束后裁判录入每张地图的比分。这里有一个容易忽视的环节无畏契约比赛中存在加时赛、平局加赛、一方弃权等情况因此比分录入不能只做一个简单的12:14还要有对局状态字段比如正常完成、弃权、判负。最后系统根据胜负关系推进淘汰赛进度生成下一轮对阵直到决出冠军。这个流程拆完我们就知道平台的基础模块应该包括赛事管理、队伍管理、报名审核、赛程生成、比分管理、数据看板。而弹幕、直播、动态资讯这类东西属于锦上添花不是核心闭环。1.2 角色权限主办方、裁判、队长各能干什么赛事平台天然带有多角色属性权限设计直接决定了系统会不会乱套。我把角色分成五类主办方/管理员创建赛事、审核报名、编辑赛程、调整对阵、指定裁判、处理争议、导出结果。裁判查看自己被安排的场次录入小局比分标记弃权关停对局。队长创建队伍、发起报名、修改队员名单、查看赛程。普通队员查看自己和队伍的赛程与比分不拥有操作权限。观众这里指的是登录后的普通用户可以浏览赛事详情、队伍信息和实时比分。最容易被忽略的是裁判身份。很多赛事系统的裁判权限和管理员混在一起这在实际使用中很危险。以我的经验裁判应当是独立的权限域只对自己负责的那一场有写权限不能让裁判随便修改整个赛事状态。1.3 功能边界什么该做进平台什么不该做想用一套系统解决所有问题是这类项目最常见的失败原因。我的建议是划清边界不该做进平台的是对局内的实时数据。无畏契约的 API 不向普通开发者开放实时对局数据强行做只会陷入合规和接口稳定性的泥潭。赛程管理平台管的是比赛之外的组织流程对局内的地图比分由裁判手动录入这是现实可行的方案。直播流、语音频道、对战房间对接等都不应该是初版的内容。先把报名、赛程、比分这三件事跑通平台就已经能支撑一场几十个队伍的赛事了。这个边界意识比任何技术选型都重要。2. 技术选型与项目骨架为什么是 Spring Boot 而不是其他方案2.1 后端框架Spring Boot 3 与 Java 17 的选择逻辑Spring Boot 3.x 是目前最合理的选择。它基于 Spring Framework 6强制要求 Java 17 起跳这意味着我们可以稳定使用record、sealed interface、text block这些语法糖代码写起来比 Java 8 时代舒服太多。而且 Spring Boot 3 内置了对 GraalVM Native Image 的支持。虽然赛事平台这种规模的服务用不上原生编译但如果未来想压到很低的资源占用或者部署到无服务器平台这套体系可以平滑扩展。反过来如果你所在团队还在用 JDK 8那也可以选 Spring Boot 2.7核心逻辑不变只是部分自动配置写法需要倒退。我个人的习惯是新项目一律 Boot 3.2除非团队明确不能升级 JDK。2.2 数据存储与缓存MySQL 和 Redis 各管哪一块赛事平台的数据量不算大MySQL 8 Redis 的组合完全够用。MySQL 承载所有结构化数据包括用户、队伍、赛事、赛程、比分。Redis 做的事情是缓存热点数据与做实时中转。最典型的场景是赛事详情页。一次赛事发布后详情页的访问往往集中在报名开放那几天里面涉及赛事信息、参赛队伍列表、当前报名状态。这些数据如果每次都查 MySQL虽然不至于把库打崩但完全没必要。用 Redis 缓存一个汇总结构每次报名审核通过后主动失效缓存体验会好很多。Redis 的第二项职责是 WebSocket 多实例消息转发这个后面单独展开。MySQL 选型上我建议直接上 8.0原因是它支持窗口函数、公共表表达式后续做积分排名、胜率统计会很方便。5.7 也能跑但写 SQL 时总有一种手被绑住的感觉。2.3 实时比分推送为什么是 WebSocket 而不是轮询比赛过程中观众最关心的是比分实时变化。轮询也能实现但存在两个问题一是轮询间隔短了浪费资源间隔长了比分更新有延迟二是比赛群情激动的时候所有观众同时高频刷新对服务端压力不小。WebSocket 是更合理的方案。一次连接建立后服务器可以把比分变化直接推给客户端。Spring Boot 里用spring-boot-starter-websocket就能做核心逻辑并没有想象中复杂。订阅模式上我建议按赛事维度做主题而不是按场次维度。观众进到赛事直播间页面时需要看到的是当前正在进行的多场比赛订阅赛事主题一次拿到所有场次更新前端再按场次分发到对应位置。2.4 鉴权方案JWT 还是 Session怎么选更省心对于这种非强监管的内部系统JWT 是更常用的方案。原因在于赛事平台通常是前后端分离部署APP 或小程序端拿 token 做身份标识非常方便。而且无畏契约比赛一般是一个赛事一个页面无状态鉴权可以避免 Session 在多实例部署时的共享问题。JWT 的缺点也很明确难以主动撤销。裁判要修改一场比赛但如果他的账号被禁用了已经签发的 token 在过期前仍然有效。解决这个问题的方法是在 Redis 里维护一个用户禁用标记每次请求时做一次 O(N) 的检查N 是响应链路里的必要拦截器数量。如果项目只在局域网内给几个管理员用Session Cookie 反而更省事。但如果考虑到未来可能对接网页端、小程序端、管理后台多端我仍然推荐 JWT。3. 数据库建模六张表撑起整个赛程体系数据库设计是赛事平台最容易返工的部分。我之前见过一个项目把比分直接存在赛程表的两个整数字段里结果做 BO5 加赛时只能加列最后一张表有二十多个比分列维护起来痛不欲生。3.1 六张核心表的关系设计我按最小可用原则设计了六张表用户表、队伍表、赛事表、报名表、赛程表、小局比分表。用户表存储账号、昵称、角色、游戏 ID不做花哨设计但role字段要加索引因为很多查询是按角色筛选的。队伍表的核心字段是队名、队长 ID、队伍状态。这里要注意队伍和用户是多对多关系但运动员只需记录队长 ID普通约束队员再通过一张团队选手关联表来实现。初版为了简单可以直接用JSON类型的members字段存队员 ID 列表MySQL 8 对 JSON 的查询支持还算可用。等到需要统计某个选手参加过哪些队伍时再归一化成关联表不迟。赛事表是主核心表字段包括赛事名称、状态、报名开始/结束时间、比赛开始时间、最大队伍数量、当前队伍数量、赛制类型。status字段用字典值约束DRAFT、REGISTERING、ONGOING、FINISHED、CANCELED。报名表连接队伍和赛事多一个status字段表示待审核、通过、驳回。这个表必须加唯一索引后面讲并发时再细说。赛程表是整个系统里信息量最大的表。它的设计直接决定后续开发顺不顺利。3.2 赛程表如何存 BO3 比分一行还是多行这是整个数据库设计里最容易走偏的地方。我的做法是赛程主表一行代表两队之间的一场比赛包括赛事 ID、轮次、场次编号、参赛双方、裁判 ID、赛程状态、计划比赛时间。两支队伍的大比分字段也挂在这个表里比如team1_score和team2_score这样赛事对阵图可以高效读取。然后单独建一个小局比分表match_detail字段包括赛程 ID、小局序号、地图名称、双方小分、胜方队伍 ID。举个例子一场 BO3 打完赛程主表存储的是team1_score2, team2_score1小局比分表有三行记录分别记录第一张地图、第二张地图、第三张地图是几比几。这种设计的好处是显而易见的对阵图列表只看赛程主表不需要聚合小局数据查询性能好。BO1、BO3、BO5 是小局数量的差异而不是表结构的差异。观众点进去看单场详情时再查小局比分表数据天然按地图分组。如果贪图省事把比分全塞在赛程主表里遇到加赛和地图异议处理时会非常痛苦。3.3 状态机字段让赛事流转不失控赛事、赛程、报名三个核心实体都需要状态字段并且状态迁移最好由专门的方法控制而不是在 Service 里随手setStatus。赛事状态迁移看起来简单但实际项目里很容易出现报名结束时间还没到比赛状态就变成进行中这类低级问题。我的做法是在TournamentService里写一个统一的状态流转方法每次迁移都做校验public void transitionTo(TournamentStatus target) { if (!currentStatus.canTransitionTo(target)) { throw new IllegalStateException(非法状态迁移); } this.status target; }currentStatus是一个枚举内部定义好允许跳转的目标集合。比如REGISTERING可以跳到ONGOING、FINISHED、CANCELED但不能跳到DRAFT。这种枚举 白名单的方式比引入状态机框架更轻量也更容易让新接手的人看懂。3.4 索引与约束并发报名时怎么防超卖赛事报名会出现典型的并发超卖问题赛事名额只剩 1 个但最后时刻有 30 个队伍同时点击报名如果没有约束就会出现 30 个报名记录同时通过、赛事实际队伍数超过上限。解决方案是三层配合第一层是报名表上加唯一索引同一队伍不能重复报名同一赛事ALTER TABLE tournament_apply ADD UNIQUE KEY uk_tournament_team (tournament_id, team_id);第二层是更新赛事当前队伍数时使用条件更新而不是先查后改int updated tournamentMapper.updateCurrentTeamCount(tournamentId, maxTeams); // SQL: UPDATE tournament SET current_teams current_teams 1 // WHERE id ? AND current_teams max_teams只有updated返回 1 才说明名额抢占成功。第三层是报名通过的操作放在一个事务里先锁定报名记录再更新队伍数最后提交。有了这三层并发场景下基本不会翻车。4. 核心接口实现创建赛事、报名审核与对阵生成这一部分直接讲接口怎么设计。我没有采用过度复杂的 DDD 架构而是保持分层简单Controller 只做参数接收和响应包装Service 做业务校验和状态流转Mapper 层直接用 MyBatis-Plus 的基础能力。4.1 创建赛事接口参数、校验与草稿机制创建赛事接口我建议采用草稿 发布两步走。管理员先保存一份不完整的赛事草稿填好信息后再点发布发布动作才触发状态迁移和公告推送。接口请求体大致长这样{ name: 春季无畏契约公开赛, rule: BO3, maxTeams: 32, registerStartTime: 2025-03-01T10:00:00, registerEndTime: 2025-03-10T22:00:00, startTime: 2025-03-15T14:00:00, description: 比赛细则 }Service 层的校验逻辑需要覆盖这几条报名结束时间必须晚于报名开始时间比赛开始时间必须晚于报名结束时间最大队伍数不能小于 2且建议是 2 的幂次避免淘汰赛生成时出现轮空逻辑复杂化赛事状态必须是DRAFT才能执行发布。发布后把赛事详情写入 Redis 缓存并记录一条操作日志。4.2 报名与审核接口事务边界要清楚报名接口的调用者是队长传入tournamentId和队伍 ID。Service 层要做五件事一是赛事必须处于REGISTERING状态二是队伍状态必须是审核通过三是校验当前队伍数是否已满四是插入报名记录状态为待审核五是返回报名 ID。审核接口的设计有一个容易踩的坑直接在tournament_apply表上做 update不同步更新队伍数量。正确做法是当审核通过时在同一个事务里做更新报名状态 赛事队伍数 1。还要考虑驳回后的处理如果队伍被驳回报名记录保留但状态改为REJECTED方便主办方查看历史记录同时名额释放给其他队伍。这里不要把记录删掉保留痕迹对后续争议处理很重要。4.3 对阵生成算法单败淘汰的实际实现思路对阵生成是很多开发者最没底的部分实际算法并不复杂。单败淘汰制的核心是严格按照战队数量计算轮次。如果参赛队伍数不是 2 的幂就会出现轮空。我的处理方式是先计算出参赛队伍数的下一个 2 的幂不够的队伍直接第一轮轮空。伪代码大致是roundCount ceil(log2(teamCount)) totalSlots 2^roundCount byeCount totalSlots - teamCount然后把所有队伍填充进对阵树的叶子节点。轮空队伍直接晋级下一轮不用打比赛。双败淘汰制要复杂很多涉及胜者组和败者组的交叉配对初版我建议先不要做。实际组织比赛时单败淘汰 复活机制就足够应付大多数校园赛和社群赛了。对阵生成后将所有赛程记录批量插入并使用事务保证不能生成一半失败。每一条赛程记录都必须带round字段方便前端按轮次渲染对阵图。4.4 比分录入接口裁判写入观众只读比分录入是写入频率最低但对准确性要求最高的接口。裁判提交的请求体应该包含赛程 ID、小局列表、每局的地图名和双方比分。后端要做几层校验赛程状态必须是IN_PROGRESS当前登录用户必须是该赛程指定的裁判小局数量必须符合赛事规则BO3 最多 3 局、BO1 最多 1 局同一场比赛中不能出现相同的地图名总分由服务端根据小局结果自动计算不允许前端传入。判胜逻辑我习惯在服务端做对比每个小局的双方比分分数高者赢得该小局先赢到规则要求局数的队伍为大比分胜者自动写入赛程主表的winner_id。这部分特别注意比分一旦录入并确认最好不要提供修改接口只提供更正接口且更正要留下日志。赛事数据的可追溯性比所谓的灵活性重要得多。5. 实时比分推送WebSocket 如何让比赛进度瞬间同步5.1 连接握手带鉴权Token 放哪WebSocket 不能像普通 HTTP 请求那样在 Header 里随便自定义浏览器端的 WebSocket API 只允许指定协议名部分旧浏览器甚至无法自定义 Header。所以常见的做法是在连接 URL 上拼token参数ws://localhost:8080/ws/tournament?tokenxxx然后实现一个HandshakeInterceptor在握手阶段拦截请求校验 token 合法性。校验通过后放行同时把用户信息写入WebSocketSession的 attributes 里方便后续从session中判断角色和订阅权限。这种方式的缺点是一个 token 可能会出现在代理日志里。如果平台要部署到公网建议把 token 换成限时有效的临时票据有效期 5 分钟换取完整身份信息。5.2 消息协议设计事件类型与载荷消息推送最忌讳的是直接把数据库实体序列化后发给前端。因为这样会造成前端每次都要根据字段分布判断这哪是什么数据一旦后端调整字段前端就崩。我推荐按事件类型组织消息比如{ event: MATCH_SCORE_UPDATED, tournamentId: 12, payload: { matchId: 56, team1Score: 2, team2Score: 1, status: FINISHED } }定义好事件类型管理类比如match.score.updated、tournament.status.changed、team.joined。前端只需要约定一个 reducer按事件类型更新对应组件状态结构清晰也不会漏消息。5.3 Redis 发布订阅多实例部署不会漏消息WebSocket 连接是有状态的一旦部署多个后端实例就会遇到观众 A 连在实例 1裁判 B 连在实例 2的情况。裁判在实例 2 上提交了比分实例 1 上的观众怎么收到答案是引入 Redis 发布订阅。比分变更消息先发布到 Redis 的某个主题所有后端实例都订阅这个主题收到消息后在自己本机保存的 WebSocket 会话里再推送一遍。代码上大致是Service 更新完比分后发布到 Redis每个实例有一个RedisMessageListener接收消息再调用本机的WebSocketSessionManager按订阅关系推送。这个模式比直接在本机推多了一层但解决了横向扩展的全部问题。5.4 断线重连与补偿轮询兜底WebSocket 在移动网络下很容易断开不做重连的页面用户体验会非常差。前端需要在onclose后启动指数退避重连比如 1 秒、2 秒、4 秒……最大间隔 30 秒。同时只靠重连还不够因为断开期间服务器推送的比分更新已经丢了。所以服务端要提供一个当前赛事快照接口前端重连成功后会先调用一次快照接口把最新比分拉回来再和本地状态做合并。我用一个简单的约定快照接口返回当前所有进行中赛程的比分前端以快照为准覆盖本地状态。这样即使丢失几条推送也不会长期显示错误比分。6. 权限控制与状态机避免谁都能改比分的乱局6.1 基于 RBAC 的三张基础表权限设计我采用最标准的 RBAC 思路用户表、角色表、用户角色关联表。但赛事平台的角色数量固定不需要做成完整的权限点—角色—用户三层结构省掉权限点表直接在角色枚举里写死功能权限即可。角色枚举public enum Role { ADMIN, // 主办方 REFEREE, // 裁判 CAPTAIN, // 队长 PLAYER, // 队员 VIEWER // 观众 }设定角色后注册接口默认创建观众角色管理员在后台可以把指定用户的角色提升为裁判或队长。我不建议让用户自行申请裁判裁判必须由管理员从赛事维度分配。6.2 方法级权限控制PreAuthorize 的实际用法Spring Security 开启方法级鉴权后在 Controller 方法上加注解是最直观的写法PreAuthorize(hasRole(ADMIN)) PostMapping(/tournaments) public Result createTournament(RequestBody Valid TournamentCreateRequest request) { ... }裁判的权限需要更细的验证不是裁判角色就能改所有场次而是要验证他是不是这场比赛的指定裁判。这种场景PreAuthorize里写复杂表达式很痛苦我建议在 Service 层做一次显式校验if (!match.getRefereeId().equals(currentUserId())) { throw new ForbiddenException(你不是本场裁判); }角色注解管谁能调用这个接口Service 内校验管谁能操作这笔数据两者配合权限才不会漏洞百出。6.3 状态流转校验把规则关进枚举里状态机除了前文说的枚举白名单方式我还会把哪些角色可以触发这个迁移也放进枚举定义里。比如REGISTERING状态迁移到ONGOING只有管理员能做IN_PROGRESS赛程迁移到FINISHED只有指定裁判能做。这种设计的本质是把规则内聚到状态定义里而不是散落在各种 Service 中。后续新增一种暂停比赛的状态时只需要修改枚举不需要满项目找 if。6.4 操作日志和审计争议发生时有据可查比赛这种场景争议免不了。有人会说比分录错了、赛程改了没通知。所以从第一版就要做简单操作日志表。日志表记录操作人、操作类型、操作对象、操作前状态、操作后状态、操作时间、IP甚至可以记录请求体摘要。录入接口的日志尤其重要。这样任何争议发生时翻日志就能还原现场而不是靠嘴争。7. 落地踩坑几种实际项目中常见的翻车场景与解法7.1 时区问题比赛日期显示和推送时间对不上赛事平台经常出现报名时间差 8 小时的问题。原因很简单服务器运行在 UTC 时区前端展示用的是浏览器本地时区。我的解决方法是统一规范数据库连接串必须加serverTimezoneAsia/ShanghaiSpring Boot 的 Jackson 配置统一使用Asia/Shanghai时区前端所有时间展示基于 ISO 8601 字符串解析不依赖后端格式化好的时间字符串。这样无论部署在哪台服务器上业务时间都是稳定的。7.2 数据库表名关键字冲突match是 MySQL 的保留字如果直接把赛程表命名为match写 SQL 必须加反引号各种 ORM 也可能踩坑。我第一次做的时候就把表名定为match结果 MyBatis-Plus 生成的 SQL 里查询没问题但某些动态条件拼接偶尔报语法错误排查半天才发现是关键字冲突。解法有两个表名直接叫match_info或者从一开始就使用mc前缀如mc_tournament、mc_match、mc_match_detail。我后来统一了前缀风格看着整齐写起来也不用担心保留字问题。7.3 BO3 比分录入的脏数据场景用户录入比分时很容易出现第一局打了 13:11第二局打了 13:15第三局还没打完但裁判误提交了大比分 2:1的情况。我在校验逻辑里增加了一条硬性规则当赛事规则为 BO3 时只有小局列表长度为 3 且第三局的完成状态为FINISHED才允许把赛程主表状态置为FINISHED。否则只是保存比分不推进赛程状态。这种防护能在入口处拦截大部分误操作比分更正的需求会少很多。7.4 测试 WebSocket 时的模拟客户端WebSocket 接口调试不像 HTTP 那么方便Postman 的历史版本对 WS 支持也不理想。我后来直接用 Java 写一个测试客户端通过jakarta.websocket的标准 API 连接本地端口收到消息后打印事件类型和载荷。这个办法虽然土但对排查握手鉴权、消息推送路径都能覆盖到。比起在浏览器里刷页面它能快速定位消息到底有没有推到当前实例。7.5 给初学者的建议先跑通最小闭环最后想给打算做类似项目的开发者一个建议第一版只做赛事创建、队伍报名、赛程生成、比分录入这四件事。我见过不少项目在启动时非常兴奋想把直播页、弹幕墙、MVP 投票、积分商城全部做进去结果做了一两个月连赛程生成都没跑通。磨刀不误砍柴工核心链路跑通之后再逐步把观众页面漂亮起来把实时推送加上去把数据统计做丰富。功能和系统规模是螺旋式增长的一口气吃不成胖子。技术方案本身没有多神秘Spring Boot 成熟到这个程度真正的难点在于把赛事组织的业务逻辑想明白、把状态和权限边界划清楚。做到这一步平台就成功了一大半。