SpringBoot马拉松赛事报名系统：并发控制与可视化大屏实战

做毕设的同学看到马拉松赛事报名系统这类题目第一反应多半是又一个CRUD。但真正动手之后才会发现报名系统远不是增删改查那么简单热门赛事放出的名额可能在几十秒内被抢空你既要保证数据不错乱又得让用户操作流畅报名高峰期要扛得住流量赛后还要能把成绩、照片、证书这些数据串起来展示给选手。这篇文章就以一个可运行的SpringBoot马拉松赛事暨报名系统为例把它从立项到交付的完整链路拆开讲清楚包括数据库设计、接口划分、并发报名方案、数据可视化大屏、爬虫模块的合规落地以及打包成毕业设计交付时那些老师不会明说但答辩一定问的细节。无论你打算用Java还是Python重写这套思路都能直接平移过去。1. 先把这个系统拆清楚它到底在解决什么问题1.1 赛事报名业务的真实痛点马拉松赛事报名不是简单的填表缴费。我做过几次城市马拉松的线上报名业务方真正的需求往往包含这几个层次赛事发布与名额管理、选手在线报名与资格审核、缴费与退费流程、参赛号码分配、成绩录入与查询、证书下载。每一个环节背后都牵扯着状态流转和异常处理。举个最典型的例子选手提交报名后如果30分钟内没付款名额要不要释放释放之后又被别人抢走前一个选手再付款怎么处理这些业务细节不提前在设计阶段想清楚写代码的时候就会反复返工。SpringBoot作为后端框架解决的是接口层和业务层的组织问题但真正的业务复杂度全在这些状态流转里。1.2 用户角色与功能边界划分这个系统我按三类角色来做权限隔离管理员、赛事运营人员、参赛选手。管理员管全局配置和系统参数运营人员管单场赛事的报名审核、名额调整、成绩录入选手则只能操作自己的报名、缴费、成绩查询和证书下载。从数据流来看一条核心链路是赛事发布 - 名额配置 - 选手报名 - 资格审核 - 缴费 - 获得参赛号 - 赛后录入成绩 - 生成证书。这个链路中每一步都对应着后端的接口和数据表设计前端只是把这套流程呈现给不同角色。做毕业设计的时候很多同学把精力全放在前端页面漂不漂亮其实后端这条链路的完整性才是答辩老师最看重的部分。1.3 为什么SpringBoot赛事报名是好选题选这个题目有一个很实际的好处技术栈覆盖面广但业务复杂度适中。SpringBoot是当前企业级Java开发的事实标准面试和工作中都绕不开赛事报名涉及权限管理、文件上传、定时任务、消息推送、数据可视化每一个点都能单独展开成亮点。而且马拉松赛事天然带大数据属性——报名人数、完赛率、年龄段分布、性别比例、地区分布这些数据做可视化大屏时非常出效果。相比图书管理、学生管理那些被做烂了的题目赛事系统有现实业务支撑答辩时老师问你为什么这么做你答因为实际业务需要处理并发报名、名额释放、成绩统计这种回答的说服力是凭空做CRUD完全比不上的。2. 技术选型的底层逻辑每一层都在给答辩埋考点2.1 后端为什么锁死SpringBootSpringBoot不是性能最好的框架但它是生态最完整、资料最多、面试最常考的框架。选它做毕业设计性价比最高。Spring Boot 2.7.x是我建议的版本基线——Spring Boot 3.x要求JDK17很多学校的答辩环境还在JDK8版本不兼容会给自己挖坑。实际项目中我用的核心依赖包括Spring Boot Web接口层、MyBatis-Plus数据持久化省去大量XML配置、Spring Security JWT登录认证、Redis缓存并发报名预扣减、Quartz定时任务释放未支付名额、ECharts数据可视化大屏。这套组合的好处是每个组件都是目前主流技术栈里的常客简历上写出来是加分项。2.2 小程序端的技术权衡标题里强调小程序说明前端主战场是微信小程序。做小程序端有几个现实理由手机端报名是绝对的主流场景、小程序无需安装符合用户习惯、微信生态可以方便地做消息模板通知。小程序端我选原生微信小程序框架不引入uni-app。原因很简单原生框架调试直接遇到问题查社区资料最方便uni-app虽然能一套代码多端发布但编译链的坑在毕业设计时间节点上不划算。小程序端的主要页面包括赛事列表、赛事详情、报名表单、报名记录、我的证书五个模块。2.3 数据可视化为什么选ECharts数据可视化部分ECharts几乎是毕业设计的事实标准。它可以展示报名趋势折线图、赛事热门度热力图、选手地域分布地图、男女比例饼图、年龄段柱状图。关键是ECharts的社区案例库极其丰富你可以直接找到接近效果的示例改造成自己的数据渲染逻辑。可视化大屏我做成独立的HTML页面不嵌在小程序里。大屏通常是答辩现场用电脑展示的独立页面配合ECharts的炫酷效果视觉冲击力远比在小程序里嵌个图表强。2.4 爬虫模块在这个系统里的正确位置很多同学一看到爬虫两个字就往招聘网站的岗位数据上爬这没问题但放到赛事报名系统里爬虫更合理的定位是采集公开的赛事信息作为数据源补充。比如从公开渠道采集周边城市的马拉松赛事公告、天气数据、空气质量数据为系统内的赛事推荐或赛事详情展示提供辅助信息。爬虫模块我用的是Selenium Requests的组合。Requests处理静态页面Selenium处理动态渲染页面。在SpringBoot项目里我把它封装成一个独立的定时任务模块定期执行采集任务数据清洗后写入赛事资讯表。这样设计既不会让爬虫干扰主业务流程又能在答辩时单独作为一个亮点来展示。3. 数据库与接口设计报名系统最容易翻车的两个环节3.1 核心数据表的设计思路数据库设计是整篇代码的灵魂。我按业务域拆成五组核心表用户域用户表、角色表、用户角色关联表、赛事域赛事表、赛事赛道表、赛事报名配置表、报名域报名订单表、选手信息表、缴费记录表、成绩域成绩表、证书表、内容域赛事资讯表、数据采集记录表。关键设计细节在这几个地方赛事表里必须冗余一个surplus_quota字段存剩余名额而不是每次报名时count(*)统计已报名人数。否则高峰期你的数据库会被COUNT查询打爆。报名订单表要设计status状态机待支付、已支付、已取消、已退款。状态流转必须通过代码逻辑严格控制不能让前端任意跳转状态。用户表不要存明文密码用BCrypt加密。答辩老师检查数据库时看到明文密码印象分会大打折扣。订单号我用Redis自增序列拼接日期生成格式如2025060110001。这样既不依赖数据库自增主键又能保证并发下的唯一性还能从订单号直接读出报名日期。3.2 核心接口与状态机设计后端接口按照RESTful风格设计核心接口大致如下POST /api/auth/login 用户登录 POST /api/events 管理员创建赛事 GET /api/events 赛事列表分页筛选 GET /api/events/{id} 赛事详情 POST /api/events/{id}/apply 选手报名 POST /api/orders/{id}/pay 模拟支付 GET /api/users/{id}/orders 我的报名记录 POST /api/admin/events/{id}/result 录入成绩 GET /api/certificates/{id} 下载证书报名状态机的定义要明确待支付 - 已支付/已取消超时 - 已审核/待审核 - 已参赛 - 已完赛/未完赛。每个状态节点的触发条件、对应接口、异常处理都写清楚。答辩时老师问报名流程怎么设计的你把状态机画出来讲一遍基本就是满分回答了。3.3 接口安全与参数校验的细节接口安全是很多毕设容易忽略的环节。我在项目里统一做了三层防护JWT Token拦截所有非登录接口防止未授权访问参数校验统一使用Spring Validation注解防止脏数据入库全局异常处理器统一返回ResultT格式小程序端根据错误码给出不同提示。一个容易被忽略的点是前端展示的赛事列表接口必须做分页。一个大城市马拉松报名可能有几万人直接用select *查全表接口响应时间会从毫秒级直接飙升到秒级这在答辩演示时是非常尴尬的。4. 报名瞬时并发的处理防止超卖才是系统的灵魂4.1 模拟热门赛事放名额的场景马拉松报名和电商秒杀非常相似。假设一场赛事放出5000个名额开放报名那一刻可能有2万人同时点立即报名。如果没有并发控制数据库里可能只剩最后一个名额但同一瞬间有20个请求同时读到剩余名额为1判断可以报名然后全部插入成功——这就是典型的超卖问题。做毕业设计时如果你用JMeter并发测试模拟这个场景会发现默认写法超卖极其严重。这也是答辩老师非常喜欢追问的一个点你有5000个名额2万人同时抢你怎么办4.2 为什么同步锁方案在这里不适用很多同学第一反应是给报名接口加synchronized或者给方法加事务锁。单个Java实例里synchronized确实能挡住并发但问题在于它锁住的是整个报名过程包括远程调用、数据库写入、Redis缓存更新这些操作加起来可能耗时200ms。100个并发请求就会排起长队接口响应时间直接超过10秒用户体验彻底崩掉。更致命的是synchronized只在单机有效。如果你的系统将来部署多实例做负载均衡每台机器各有一个锁并发控制等于完全失效。所以从架构视角看synchronized方案从一开始就不该列入备选。4.3 Redis预扣减 数据库兜底可行的折中方案我采用的方案是Redis预扣减名额 数据库悲观锁兜底。第一步赛事发布时把剩余名额同步到Redis例如event:quota:1001 5000。 第二步报名请求进入后先用decr命令原子减一判断返回值是否大于等于0。 第三步如果减出来的值小于0说明名额已满此时把名额加回去incr直接返回名额已满。 第四步如果减出来的值大于等于0进入业务逻辑执行数据库插入插入失败时要把Redis名额加回去防止名额凭空消失。Redis的单线程命令执行机制保证了decr操作天然原子不会出现两个人同时减到同一个数的情况。这比任何代码层面的锁都高效。兜底逻辑放在数据库层报名订单表里对event_id user_id建唯一索引同一用户同一赛事只能有一条报名记录对报名表本身加SELECT ... FOR UPDATE悲观锁确保极端情况下不会重复插入。4.4 代码层面的具体落地报名接口的核心逻辑大致如下Transactional(rollbackFor Exception.class) public ApplyResult applyEvent(Long eventId, Long userId) { String quotaKey event:quota: eventId; Long surplus redisTemplate.opsForValue().decrement(quotaKey); if (surplus null || surplus 0) { redisTemplate.opsForValue().increment(quotaKey); return ApplyResult.fail(名额已满); } try { // 查询赛事信息校验报名时间窗口 Event event eventMapper.selectById(eventId); if (event null || !event.isApplying()) { throw new BizException(赛事不在报名期); } // 创建订单状态为待支付 Order order buildOrder(eventId, userId); orderMapper.insert(order); return ApplyResult.success(order); } catch (Exception e) { // 任何异常都要补偿Redis名额 redisTemplate.opsForValue().increment(quotaKey); throw e; } }注意Transactional注解与Redis操作之间的联动关系。Redis的decr在事务开启之前执行数据库异常时靠catch块补偿回滚Redis。这个做法不是最完美的但胜在逻辑清晰答辩时容易讲明白也经得起并发测试验证。5. 数据可视化大屏让数据自己会说话5.1 大屏整体的数据链路设计数据可视化大屏是我的项目里最能出效果的模块。整个数据链路是这样设计的业务数据落库 - 定时任务或实时接口从数据库读取统计 - 后端聚合返回JSON - ECharts渲染到页面 - 大屏轮询刷新。大屏我分成五个区域顶部是整体赛事数据总览总报名人数、完赛率、平均完赛时间中间是报名趋势折线图展示近30天报名人数变化左侧是男女比例和年龄段分布图右侧是热门赛事排行榜和地域分布图。接口层面大屏聚合接口单独写不做成散装的多个小接口。原因是大屏要展示的维度有七八个如果每个指标都单独请求一次前端要并发调七八个接口页面加载慢而且逻辑乱。一个GET /api/dashboard/overview接口直接返回完整JSON前端一次渲染完简单高效。5.2 用SQL聚合还是Java内存计算做统计报表时能用SQL聚合的就不要用Java内存计算。SQL聚合交给数据库引擎性能远高于先把数据全量查出来再在Java里做for循环统计。一个典型例子查询各年龄段报名人数分布。SELECT CASE WHEN age 18 THEN 18以下 WHEN age BETWEEN 18 AND 30 THEN 18-30 WHEN age BETWEEN 31 AND 45 THEN 31-45 WHEN age BETWEEN 46 AND 60 THEN 46-60 ELSE 60以上 END AS age_group, COUNT(*) AS cnt FROM apply_info WHERE event_id #{eventId} GROUP BY age_group这类SQL写起来不难但要注意一个坑如果前端要展示的是分组统计你的SQL里必须有GROUP BY并且返回字段名要和前端ECharts的series配置对得上。很多同学做着做着发现图表不显示十有八九是字段名匹配不上。5.3 地图和排行榜的渲染细节地域分布我用了ECharts的地图组件。ECharts官方地图数据只到中国省级粒度所以报名信息里有省份字段的按省份聚合展示如果你采集的数据精确到城市需要自己引入城市GeoJSON这会额外增加包体积加载速度会慢一些建议按需取舍。热门赛事排行榜用简单的横向柱状图实现按报名人数排序最多显示前10条。这个排行榜的SQL也要加LIMIT 10不要全量查出再截取数据量大时性能差很多。6. 爬虫模块的合规实现与工程落地6.1 采集目标与合规边界爬虫模块在这个项目里定位为赛事资讯的自动补充。我从公开渠道采集三类数据同城其他马拉松赛事的公告信息、赛事期间的天气趋势、城市AQI空气质量数据。这里必须强调合规边界只采集公开、非个人隐私、无版权争议的数据采集频率控制在每分钟不超过10次请求不给目标服务器造成压力采集到的数据只用于项目展示和学术研究不做二次商业化目标站点的robots协议如果有明确禁止就不碰。答辩时如果老师问爬虫的合法性你把这个逻辑讲清楚态度就对了。6.2 静态页面与动态页面的差异化处理采集静态页面用Requests BeautifulSoup足够了。比如城市天气数据一般是静态HTML直接解析就可以import requests from bs4 import BeautifulSoup resp requests.get(https://example.com/weather, headers{User-Agent: Mozilla/5.0}) soup BeautifulSoup(resp.text, html.parser) temp soup.select_one(.temperature).text但很多赛事公告页面是JavaScript动态渲染的Requests拿到的只是空壳HTML。这时候用Selenium带浏览器环境去加载等页面渲染完成后再取数据。Selenium虽然慢但胜在通用适合小规模采集。如果采集量特别大再考虑Playwright或Scrapy框架做并发采集。6.3 SpringBoot项目里的定时任务调度我在SpringBoot里用Scheduled注解做定时调度每天凌晨2点执行一次采集任务。凌晨执行的好处是服务器压力小也不会影响正常业务的数据库性能。采集到的数据先落到独立的采集表经过一个简单的清洗方法去重、去空值、格式化日期再写入赛事资讯表供前端展示。采集失败的情况也要处理。我在采集任务里加了try-catch和日志记录连续失败3次就发告警邮件。这个设计在答辩时可以展开讲说明你有工程化的容错意识。7. 部署、避坑与打包交付毕业设计从能跑到能交7.1 本地运行的最小化环境配置运行这个项目需要的最小环境是JDK 8、Maven 3.6、MySQL 5.7、Redis 5.0。项目里我把初始化SQL文件放在sql/目录包含建库建表语句和初始测试数据。跑起来之前需要改配置文件里的数据库账号密码和Redis地址。一个重要的建议用application-dev.yml和application-prod.yml区分开发和生产配置。答辩演示用dev配置足够但代码里体现了不同环境配置的概念会显得你更有工程经验。7.2 常见部署问题与排查思路端口被占用SpringBoot默认8080端口经常被其他程序占掉启动报错后先netstat -ano | findstr 8080查看占用进程。数据库时区报错MySQL 8.x连接时区问题很常见在JDBC连接串里加serverTimezoneAsia/Shanghai。Redis连接不上本地没启动Redis服务就启动项目会直接启动失败。先启动Redis再启动SpringBoot。小程序端访问不到后端本地调试时小程序默认不能访问localhost需要在微信开发者工具里勾选不校验合法域名并且把后端接口地址改成局域网IP或内网穿透地址。7.3 源码整理与交付的细节毕设源码交付最忌讳的就是把一团乱麻直接丢给老师。我交付时按四个模块分包backendSpringBoot后端完整源码、miniapp小程序前端源码、dashboard独立的数据可视化大屏页面、docs项目文档和答辩PPT素材。源码里我加了两样东西后来证明非常有用一是README.md写清楚项目介绍、技术栈、部署步骤、默认账号密码二是项目目录结构说明文档把每个包的作用写清楚方便老师快速定位代码。答辩现场老师直接翻开你的源码问这个定时任务在哪你能三秒钟指出来这个印象分是实打实的。7.4 最后分享两个实操心得第一个心得早点把数据库的初始化数据和时序数据准备好。很多同学做可视化大屏接口写完了没有数据展示一片空白。我提前用脚本生成了一批模拟报名数据男女比例、年龄段、地域分布都符合现实分布规律大屏一打开就有内容视觉效果直接拉满。第二个心得答辩时不要只演示功能要准备一个惊险故事。比如你可以说做并发报名测试的时候我一开始用synchronized发现超卖严重后来改用Redis预扣减才解决。这种解决问题的叙事比干巴巴讲功能有效得多。另外爬虫模块演示时一定要提前录好视频现场连外网采集容易被反爬或网络波动卡住提前录制的演示视频是最安全的方案。