当前位置：首页 > news >正文

基于Java Web的毕业设计选题系统设计与实现：从需求建模到高并发选题冲突处理

news 2026/3/26 21:13:13

背景痛点：当“抢课”遇上毕业设计

每到毕业季，高校教务老师和学生都会面临一场无声的“战争”——毕业设计选题。传统的线下或简单线上流程，在选题高峰期往往会暴露出诸多问题，成为系统设计的核心痛点。

高并发下的“秒杀”困境：选题系统开放瞬间，大量学生同时点击“确认选题”，极易引发超选、重复占用等数据不一致问题。这本质上是一个典型的“秒杀”场景，对系统的并发处理和数据一致性提出了严峻挑战。
重复提交与幂等性缺失：网络延迟或用户急躁地多次点击提交按钮，可能导致同一学生为同一课题提交多次申请，或产生多条重复的申请记录，给后续的教师审核和系统统计带来混乱。
僵化的线性流程：许多早期系统采用简单的“学生选-教师审”线性状态流转。但当流程需要加入“教研室主任审核”、“院系审批”或“学生中期可申请换题”等环节时，原有硬编码的状态判断逻辑就会变得难以维护和扩展，系统灵活性差。
安全与审计的盲区：谁在什么时间修改了课题信息？哪位教师审核了哪位学生的申请？缺乏完整的操作日志，一旦出现争议或误操作，将无从追溯，给教学管理带来风险。

技术选型对比：为什么是它们？

面对上述痛点，合理的技术选型是构建稳健系统的基石。我们对比了两种常见的技术组合。

Spring Boot vs 传统SSM (Spring + Spring MVC + MyBatis)

传统SSM框架需要开发者手动配置大量的XML文件（如spring-mvc.xml,spring-mybatis.xml）和web.xml，集成过程繁琐，且容易因配置不当引发问题。对于毕业设计选题系统这类需要快速迭代、清晰架构的项目，我们优先选择Spring Boot。

理由：Spring Boot遵循“约定大于配置”的原则，提供了强大的起步依赖（Starter），能一键式构建独立运行、生产级的Spring应用。它内嵌了Tomcat等Servlet容器，简化了部署；同时，其自动配置机制和Actuator监控端点，极大地提升了开发效率和系统的可观测性。这使得开发团队能将精力更集中于业务逻辑（如选题冲突处理）而非框架整合。

Redis vs ZooKeeper 在分布式锁场景下的权衡

解决高并发选题冲突，分布式锁是关键。Redis和ZooKeeper是两种常见的实现方案。

Redis实现分布式锁：通常使用SET key value NX PX timeout命令。其优点是性能极高，实现相对简单，社区成熟（如Redisson客户端提供了完善的锁实现）。缺点是它基于异步复制，在极端的主从故障切换场景下可能存在锁失效的风险（尽管概率极低）。对于毕业选题这类对锁的绝对一致性要求并非金融级、但吞吐量要求高的场景，Redis是更合适的选择。
ZooKeeper实现分布式锁：利用其有序临时节点和Watch机制。优点是强一致性，锁模型健壮。缺点是性能相对Redis较低，且引入了额外的系统复杂性和运维成本。

我们的选择：鉴于毕业设计选题系统通常部署在校园网内，集群规模有限，对性能要求高于对极端一致性的要求，我们选用Redis来实现分布式锁，以保障高并发下的系统吞吐能力。

核心实现：代码驱动的解决方案

1. 幂等性设计与分布式锁

选题接口必须具备幂等性，即同一学生对于同一课题的多次请求，只有一次生效。我们结合“业务唯一键（学生ID+课题ID）”与Redis分布式锁来实现。

@Service public class TopicSelectionService { @Autowired private StringRedisTemplate redisTemplate; @Autowired private TopicApplicationMapper applicationMapper; public ApiResult selectTopic(Long studentId, Long topicId) { // 构造业务唯一标识和锁键 String bizKey = "select:" + studentId + ":" + topicId"; String lockKey = "lock:" + bizKey"; String requestId = UUID.randomUUID().toString(); // 用于标识当前请求，避免误删其他请求的锁 // 尝试获取分布式锁，锁持有时间设为3秒，防止死锁 Boolean locked = false; try { locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, 3, TimeUnit.SECONDS); if (Boolean.FALSE.equals(locked)) { return ApiResult.fail("系统繁忙，请稍后重试"); } // 加锁成功后，检查幂等性：是否已存在申请记录 TopicApplication existing = applicationMapper.selectByStudentAndTopic(studentId, topicId); if (existing != null) { return ApiResult.fail("您已申请过该课题，请勿重复提交"); } // 执行核心选题业务逻辑（此处省略，下方乐观锁部分会展开） return doSelectTopicWithOptimisticLock(studentId, topicId); } finally { // 释放锁：使用Lua脚本保证原子性，仅当锁的value与当前请求ID一致时才删除 if (Boolean.TRUE.equals(locked)) { String luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end"; redisTemplate.execute(new DefaultRedisScript<>(luaScript, Long.class), Collections.singletonList(lockKey), requestId); } } } }

2. 数据库层面的乐观锁

分布式锁解决了集群间并发问题，但在应用内，数据库更新操作仍需防止并发导致的数据覆盖。我们在课题表（topic）中引入一个version字段（版本号），实现乐观锁。

// Topic 实体类 @Data public class Topic { private Long id; private String title; private Long teacherId; private Integer selectedCount; // 已选人数 private Integer maxCount; // 最大可选人数 private Integer version; // 乐观锁版本号 // ... 其他字段 } @Service public class TopicSelectionService { @Transactional(rollbackFor = Exception.class) public ApiResult doSelectTopicWithOptimisticLock(Long studentId, Long topicId) { // 1. 查询当前课题信息，携带version Topic topic = topicMapper.selectByIdForUpdate(topicId); // 注意：这里用了for update? 不，乐观锁通常不用。这里仅为查询。 if (topic == null) { return ApiResult.fail("课题不存在"); } if (topic.getSelectedCount() >= topic.getMaxCount()) { return ApiResult.fail("该课题名额已满"); } // 2. 基于查询到的version，执行条件更新 int updatedRows = topicMapper.increaseSelectedCountWithVersion(topicId, topic.getVersion()); if (updatedRows == 0) { // 更新行数为0，说明version已变更（即数据已被其他线程修改），乐观锁冲突 throw new OptimisticLockingFailureException("选题竞争激烈，请重试"); } // 3. 乐观锁更新成功后，创建申请记录 TopicApplication application = new TopicApplication(); application.setStudentId(studentId); application.setTopicId(topicId); application.setStatus(ApplicationStatus.SUBMITTED.getCode()); // 状态：已提交 applicationMapper.insert(application); // 4. 记录操作日志（审计） operationLogService.log(studentId, "TOPIC_SELECT", "申请课题：" + topic.getTitle()); return ApiResult.success("选题申请提交成功，等待教师审核"); } }

对应的MyBatis Mapper XML中的更新SQL：

<update id="increaseSelectedCountWithVersion"> UPDATE topic SET selected_count = selected_count + 1, version = version + 1, update_time = NOW() WHERE id = #{topicId} AND version = #{version} <!-- 关键：将查询到的version作为更新条件 --> AND selected_count < max_count <!-- 同时再次校验名额，双重保障 --> </update>

3. 状态机驱动的业务流程

为了管理“提交 -> 教师审核 -> (驳回/通过) -> 学生确认 -> 最终锁定”等复杂流程，我们引入状态机（State Machine），避免在代码中写满if-else的状态判断。

我们使用Spring State Machine或轻量级的枚举+策略模式来实现。核心是定义清晰的状态枚举和事件枚举。

// 申请状态枚举 public enum ApplicationStatus { SUBMITTED(1, "已提交"), TEACHER_APPROVED(2, "教师通过"), TEACHER_REJECTED(3, "教师驳回"), STUDENT_CONFIRMED(4, "学生已确认"), FINALIZED(5, "最终锁定"), CANCELLED(6, "已取消"); // ... 构造方法，getter } // 状态机处理器（简化示例） @Component public class ApplicationStateMachineProcessor { public ApplicationStatus handleEvent(ApplicationStatus currentStatus, ApplicationEvent event, TopicApplication application) { switch (currentStatus) { case SUBMITTED: if (event == ApplicationEvent.TEACHER_APPROVE) { // 执行审核通过的业务逻辑... return ApplicationStatus.TEACHER_APPROVED; } else if (event == ApplicationEvent.TEACHER_REJECT) { // 执行审核驳回的逻辑... return ApplicationStatus.TEACHER_REJECTED; } break; case TEACHER_APPROVED: if (event == ApplicationEvent.STUDENT_CONFIRM) { // 学生确认，需要检查课题名额是否依然可用（可能被其他教师并行操作） boolean success = topicService.confirmSelection(application.getTopicId()); return success ? ApplicationStatus.STUDENT_CONFIRMED : ApplicationStatus.CANCELLED; // 名额不足则取消 } break; // ... 其他状态转换 default: throw new IllegalStateException("不支持的状态转换"); } return currentStatus; } }

通过状态机，流程变更（如增加一个“系主任审批”环节）只需修改状态枚举和转换逻辑，业务服务层代码保持清晰。

性能与安全：不容忽视的基石

数据库索引优化

聚簇索引：topic表的主键id，application表的主键id。
唯一索引：application表上的(student_id, topic_id)，防止数据库层面的重复申请（幂等的最后防线）。
复合索引：application表上的(topic_id, status)，加速教师查询自己名下课题的申请列表（WHERE topic_id IN (?) AND status = ?）。application表上的(student_id, status)，加速学生查询自己的申请历史。
覆盖索引：对于频繁查询但只返回少数字段的接口（如只查课题ID和标题），考虑建立包含这些字段的索引，避免回表。

防刷机制

接口限流：使用Guava RateLimiter或Spring Cloud Gateway对/api/topic/select等核心接口进行限流，例如每名学生每秒最多请求1次。
验证码：在选题提交页面，集成简单的图形验证码或滑动验证，虽然影响一点用户体验，但能有效防止脚本恶意刷题。
业务规则限制：在业务逻辑中强制规定，如“每名学生最多同时存在3个待审核的申请”、“选题开始后30分钟内不允许撤销后立即重选同一课题”等。

操作日志追踪

所有关键业务操作（选题、审核、确认、课题信息修改）都必须记录操作日志。日志表(operation_log)应包含：操作人ID、操作人类型（学生/教师/管理员）、操作类型、操作目标ID、操作前快照（JSON）、操作后快照（JSON）、IP地址、时间戳。这不仅是安全审计的需要，在出现数据异常时，也能快速定位问题原因，甚至用于数据修复。

生产避坑指南

事务边界与锁失效：在“获取Redis锁 -> 执行业务 -> 释放锁”的流程中，业务方法doSelectTopicWithOptimisticLock被标记了@Transactional。要确保获取锁的操作在事务之外。如果先开启事务再获取锁，那么事务提交前，其他线程可能因为读不到未提交的数据而判断资源可用，导致锁失效。正确的顺序是：先获取分布式锁，再开启数据库事务执行业务。
连接池与冷启动：在选题系统开放瞬间（冷启动），大量请求涌入，如果数据库连接池（如HikariCP）初始连接数(minimumIdle)设置过小，会瞬间创建大量新连接，导致数据库压力陡增和请求延迟。建议适当调高minimumIdle，并配合合理的maximumPoolSize和连接超时时间。
Redis锁的过期时间：锁的过期时间不宜过短（业务未执行完锁就释放）或过长（业务异常退出后锁长期不释放）。需要根据业务平均执行时间合理设置，并考虑使用Redisson的看门狗机制自动续期。
缓存与数据库一致性：如果使用了缓存（如Redis缓存课题信息），在教师修改课题名额后，必须同步或失效对应的缓存。可以采用“先更新数据库，再删除缓存”的策略，虽然存在极短时间的不一致，但简单有效。
日志级别与性能：在高峰期，将日志级别调整为WARN或ERROR，避免大量INFO/DEBUG日志刷盘影响磁盘I/O和应用性能。