简介在Web应用开发领域SpringBoot作为Java生态中广受欢迎的框架以其“约定大于配置”的理念极大地简化了企业级应用的开发与部署流程。其核心原理在于通过自动配置和起步依赖快速整合Web、数据访问、安全等模块显著提升开发效率。结合MySQL这一成熟的关系型数据库能够为需要强事务一致性和复杂查询的业务系统提供稳定可靠的数据存储方案。这种技术组合在构建具备真实业务价值的应用时尤为重要例如在线预约系统。这类系统面临的核心技术挑战之一便是高并发下的资源竞争问题即“超卖”现象。通过合理的数据库表设计如引入状态字段和唯一约束并结合乐观锁或分布式锁等并发控制机制可以有效保障数据的一致性。支付集成则是另一个关键环节需要处理好异步回调、幂等性和事务完整性以确保资金流与业务状态的同步。本文将以一个典型的羽毛球馆在线预约系统为具体案例深入剖析如何使用SpringBoot和MySQL实现从用户预约、并发控制到支付集成的完整闭环为开发者提供一个可落地的、涵盖核心业务逻辑与典型技术难点的实战参考。1. 项目概述从“交作业”到“练真功”的蜕变又到了一年一度的毕业季对于计算机相关专业的同学来说最头疼的莫过于那个绕不开的“毕业设计”。我见过太多同学面对这个任务时第一反应就是去网上搜“XXX系统源码”找到一个能跑起来的压缩包改改界面、修修Bug就匆匆提交了。如果今天你搜到的是“java羽毛球馆在线预约系统源代码springbootmysql说明文档LWPPT”并且点进了这篇文章那么恭喜你你找对地方了。但我的目的不是给你一个现成的、改改就能交差的“作业”而是想和你一起把这个看似简单的“羽毛球馆预约系统”当作一个完整的、真实的、可上线的商业项目来剖析和构建。为什么是羽毛球馆因为它太典型了。它涵盖了用户端会员预约、查看场地、管理端场地管理、订单处理、支付、定时任务清理超时未支付订单、甚至简单的数据分析热门时段统计等核心模块。麻雀虽小五脏俱全。用SpringBoot MySQL这套经典组合来实现它不仅能让你顺利毕业更能让你把学校里学的Java Web、数据库、前后端交互这些知识真正串起来形成项目经验。这篇文章我会以一个“过来人”兼项目实战者的角度带你从零开始深入这个项目的每一个技术细节和业务逻辑让你知其然更知其所以然。无论你是正在为毕设发愁的同学还是想找一个SpringBoot练手项目的开发者这篇文章都将是一份详尽的“避坑指南”和“实战手册”。2. 项目整体设计与架构选型2.1 为什么是SpringBoot MySQL看到这个技术栈你可能觉得老生常谈。但经典之所以成为经典是因为在大多数场景下它是最优解。对于毕业设计或者中小型创业项目初期选择技术栈的核心原则是成熟、稳定、社区丰富、开发效率高。SpringBoot完美契合了这些要求。它通过“约定大于配置”的理念极大地简化了Spring应用的初始搭建和开发过程。你不用再被繁琐的XML配置和依赖冲突折磨一个SpringBootApplication注解就能启动一个Web服务器。内嵌的Tomcat让你无需单独部署War包spring-boot-starter-*系列依赖能让你像搭积木一样引入数据访问、安全、缓存等功能。对于羽毛球馆预约系统来说我们可能用到的spring-boot-starter-webWeb开发、spring-boot-starter-data-jpa或mybatis-spring-boot-starter数据持久层、spring-boot-starter-security安全控制等都能轻松集成。MySQL作为最流行的开源关系型数据库其优势在于事务的ACID特性、完善的SQL支持以及海量的实践案例。预约系统的核心数据如用户信息、场地信息、订单记录都是强关系型数据需要保证数据的一致性和完整性例如一个场地在同一时间段只能被一个有效订单锁定。MySQL的事务机制和行级锁能很好地支持这一点。虽然有人会说“用MongoDB存JSON更灵活”但对于业务逻辑清晰、表结构固定的系统关系型数据库在复杂查询和事务处理上的优势是不可替代的。注意很多同学在毕设中为了“炫技”盲目引入Redis、RabbitMQ、Elasticsearch等中间件结果项目核心功能一塌糊涂中间件也只是简单配置毫无实际应用场景。这是大忌。我们的原则是如无必要勿增实体。在本系统一期完全可以只用SpringBoot和MySQL。如果后期真有性能瓶颈比如热门场地秒杀再考虑引入缓存和队列。2.2 核心业务模块拆解一个完整的在线预约系统绝不仅仅是一个“增删改查”CRUD。我们需要从用户和管理员两个视角来拆解功能。用户侧核心流程注册/登录支持手机号验证码或密码登录。这里涉及短信服务集成如阿里云、腾讯云SMS。场地浏览与查询按日期、时段、场地类型如室内/室外筛选可用场地。这里是业务逻辑的起点查询的效率和准确性是关键。预约下单选择场地、时段确认价格生成订单。这里的核心并发问题是“超卖”如何确保多个用户同时预约同一时段同一场地时只有一个成功。支付集成微信支付或支付宝。订单状态需与支付回调紧密联动未支付、已支付、已取消、已完成。个人中心查看我的订单历史、待支付、已预约、取消预约需考虑退款规则、个人信息管理。管理侧核心功能场地管理CRUD场地信息名称、类型、图片、介绍、不同时段的定价策略。定价策略可以很灵活比如工作日/周末价格不同黄金时段晚上价格上浮。订单管理查看所有订单处理退款申请手动调整订单状态。用户管理查看注册用户禁用违规账号。数据统计简单的仪表盘展示每日/每月的预约数量、营收情况、热门场地排行。这部分能为场馆运营者提供决策支持。系统设置如可预约的日期范围例如只能预约未来7天的场地、每个时段时长如1小时/节、自动取消未支付订单的时限如15分钟。2.3 技术架构图与数据流虽然我们不画复杂的架构图但在脑子里要有清晰的层次概念。一个典型的SpringBoot应用会采用分层架构控制层Controller接收HTTP请求进行参数校验推荐使用Valid注解调用服务层返回JSON响应。例如BookingController会有/api/booking/create接口。服务层Service核心业务逻辑所在地。例如BookingServiceImpl中的createOrder方法会包含检查场地可用性、生成订单号、计算金额、保存订单、可能调用支付接口等一连串操作。事务Transactional通常在这一层声明以保证业务操作的原子性。数据持久层Repository/Mapper负责与数据库交互。如果使用Spring Data JPA就是继承JpaRepository的接口如果使用MyBatis就是编写Mapper XML文件。这里定义数据的增删改查。实体层Entity/Domain与数据库表映射的Java对象。使用JPA时常用Entity注解。数据流可以这样理解用户点击“预约” - 前端调用BookingController.create()- 控制器校验参数后调用BookingService.createOrder()- 服务层内调用VenueRepository.findById()检查场地、BookingRepository.save()保存订单 - 服务层调用PaymentService发起支付 - 将支付所需信息返回给前端 - 前端引导用户完成支付。3. 核心细节解析与实操要点3.1 数据库设计如何避免“超卖”这是本系统的技术核心难点。设计不当就会出现“一房多卖”的尴尬局面。我们来设计核心表1. 场地表venueCREATE TABLE venue ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键, name varchar(100) NOT NULL COMMENT 场地名称如1号场, type tinyint(4) NOT NULL COMMENT 类型1:室内 2:室外, description text COMMENT 描述, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1:可用 0:禁用, price_per_hour decimal(10,2) NOT NULL COMMENT 基础单价元/小时, images varchar(500) DEFAULT NULL COMMENT 图片URL多个用逗号分隔, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT场地信息表;2. 场地日程表venue_schedule这是关键表。我们不直接锁“场地”而是锁“场地的某个时间段”。很多初学者设计时只在订单表里记录场地ID和开始结束时间查询可用性时需要遍历所有订单进行时间冲突判断效率低且在高并发下容易出错。CREATE TABLE venue_schedule ( id bigint(20) NOT NULL AUTO_INCREMENT, venue_id bigint(20) NOT NULL COMMENT 场地ID, schedule_date date NOT NULL COMMENT 日程日期, time_slot tinyint(4) NOT NULL COMMENT 时段编号如1代表9:00-10:00, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态0:可预约 1:已锁定 2:已预约, locked_until datetime DEFAULT NULL COMMENT 锁定截止时间用于支付超时释放, order_id varchar(32) DEFAULT NULL COMMENT 关联的订单号, PRIMARY KEY (id), UNIQUE KEY uk_venue_date_slot (venue_id,schedule_date,time_slot), KEY idx_status (status), CONSTRAINT fk_schedule_venue FOREIGN KEY (venue_id) REFERENCES venue (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT场地日程表;uk_venue_date_slot唯一索引确保同一个场地、同一天、同一个时段在数据库层面只有一条记录这是防止重复插入的第一道屏障。status字段0可预约1已锁定用户正在支付2已预约支付成功。通过状态机管理生命周期。locked_until字段用户提交订单后先将状态改为1已锁定并设置一个过期时间如当前时间15分钟。需要一个后台定时任务定期扫描状态为1且locked_until NOW()的记录将其状态重置为0。这解决了用户下单后不支付导致场地长期被占的问题。3. 订单表booking_orderCREATE TABLE booking_order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号唯一业务生成, user_id bigint(20) NOT NULL COMMENT 用户ID, venue_id bigint(20) NOT NULL COMMENT 场地ID, schedule_date date NOT NULL COMMENT 预约日期, time_slot tinyint(4) NOT NULL COMMENT 时段, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 订单状态0:待支付 1:已支付 2:已取消 3:已完成, pay_time datetime DEFAULT NULL COMMENT 支付时间, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_status (status), CONSTRAINT fk_order_venue FOREIGN KEY (venue_id) REFERENCES venue (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT预约订单表;实操心得数据库设计时时间字段尽量使用datetime或timestamp并明确时区问题。金额使用decimal类型避免浮点数精度丢失。所有外键字段都要建立索引如venue_id,user_id。update_time的自动更新在排查数据问题时非常有用。3.2 高并发下的预约锁悲观锁 vs 乐观锁当两个用户同时点击预约同一个时段时如何保证只有一个成功这就是并发控制。方案一悲观锁Pessimistic Lock在查询并修改venue_schedule记录时使用SELECT ... FOR UPDATE。这会在事务中给这条记录加上行锁其他事务必须等待。Transactional public Order createOrder(Long venueId, LocalDate date, Integer timeSlot, Long userId) { // 1. 悲观锁查询 VenueSchedule schedule venueScheduleRepository.findByVenueIdAndDateAndSlotForUpdate(venueId, date, timeSlot); if (schedule null || schedule.getStatus() ! 0) { throw new BusinessException(该时段不可预约); } // 2. 更新状态为锁定 schedule.setStatus(1); schedule.setLockedUntil(LocalDateTime.now().plusMinutes(15)); venueScheduleRepository.save(schedule); // 3. 创建订单... }这种方法简单直接在并发不高时很有效。但缺点是如果事务时间长会长时间锁住记录影响吞吐量。方案二乐观锁Optimistic Lock给venue_schedule表增加一个版本号字段version或使用更新时间update_time。更新时带上版本号作为条件。UPDATE venue_schedule SET status 1, locked_until ?, version version 1 WHERE id ? AND status 0 AND version ?;如果更新返回的影响行数为0说明在此期间记录已被别人修改本次操作失败需要提示用户“预约失败请重试”。Spring Data JPA可以通过Version注解轻松实现。方案三分布式锁Redis在分布式部署环境下数据库行锁可能不够用。可以使用Redis的SETNX或Redisson客户端实现一个分布式锁key可以是lock:venue:{venueId}:{date}:{timeSlot}在创建订单前先获取锁获取成功后再进行后续数据库操作操作完成后释放锁。我的选择与建议对于毕业设计或初期项目推荐使用“乐观锁”。因为它实现简单在并发冲突不极端的情况下性能更好。我们可以在服务层捕获更新失败异常然后返回友好的错误信息给前端前端可以提示用户“手速慢了请重新选择”。这比让用户长时间等待数据库行锁释放体验更好。在实际编码中结合venue_schedule表的唯一索引可以做到双重保障。4. 实操过程与核心环节实现4.1 项目初始化与基础框架搭建我们使用Spring Initializrhttps://start.spring.io/来快速生成项目骨架。选择Project: Maven Project (更通用)Language: JavaSpring Boot: 选择2.7.x或3.x的稳定版本注意3.x需要Java 17Dependencies:Spring Web: 构建Web应用Spring Data JPA: 数据持久化这里以JPA为例你也可以选MyBatisMySQL Driver: 连接MySQLLombok: 简化POJO代码强烈推荐Validation: 参数校验生成项目后在application.yml中配置数据库和JPAspring: datasource: url: jdbc:mysql://localhost:3306/booking_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver jpa: hibernate: ddl-auto: update # 项目初期可以用update自动建表生产环境务必改为validate或none show-sql: true # 开发时开启方便看生成的SQL properties: hibernate: dialect: org.hibernate.dialect.MySQL8Dialect format_sql: true4.2 核心业务创建预约订单服务实现让我们聚焦最核心的BookingService.createOrder方法。这里会融合数据库设计、并发控制和业务逻辑。Service Slf4j RequiredArgsConstructor // Lombok注解为final字段生成构造函数 public class BookingServiceImpl implements BookingService { private final VenueScheduleRepository scheduleRepo; private final BookingOrderRepository orderRepo; private final DistributedLockService lockService; // 假设我们用了Redis分布式锁 private final SnowflakeIdGenerator idGenerator; // 雪花算法生成订单号 Override Transactional(rollbackFor Exception.class) // 声明式事务异常回滚 public OrderDTO createOrder(CreateOrderRequest request) { Long venueId request.getVenueId(); LocalDate date request.getDate(); Integer timeSlot request.getTimeSlot(); Long userId AuthContext.getCurrentUserId(); // 从线程上下文获取当前用户 // 1. 基础校验场地是否存在、是否可用等 Venue venue validateVenue(venueId); // 2. 构建分布式锁的key String lockKey String.format(lock:booking:%d:%s:%d, venueId, date, timeSlot); // 3. 尝试获取锁设置锁超时时间防止死锁 boolean locked lockService.tryLock(lockKey, 10, TimeUnit.SECONDS); if (!locked) { throw new BusinessException(系统繁忙请稍后重试); } try { // 4. 查询日程记录这里可以不用FOR UPDATE因为锁已经由Redis管理 VenueSchedule schedule scheduleRepo.findByVenueIdAndScheduleDateAndTimeSlot(venueId, date, timeSlot) .orElseThrow(() - new BusinessException(该时段不存在)); // 5. 检查状态是否可预约 if (schedule.getStatus() ! ScheduleStatus.AVAILABLE.getCode()) { throw new BusinessException(该时段已被预约); } // 6. 乐观锁更新状态 int updateCount scheduleRepo.lockSchedule(schedule.getId(), ScheduleStatus.LOCKED.getCode(), LocalDateTime.now().plusMinutes(15)); if (updateCount 0) { // 乐观锁更新失败说明状态已被其他请求改变 throw new BusinessException(预约失败请重新选择); } // 7. 生成订单号使用雪花算法避免重复和可猜测 String orderNo idGenerator.nextIdStr(); // 8. 计算金额这里可以扩展复杂的计价规则如会员折扣、时段溢价 BigDecimal amount calculateAmount(venue, date, timeSlot); // 9. 创建订单实体并保存 BookingOrder order new BookingOrder(); order.setOrderNo(orderNo); order.setUserId(userId); order.setVenueId(venueId); order.setScheduleDate(date); order.setTimeSlot(timeSlot); order.setTotalAmount(amount); order.setStatus(OrderStatus.PENDING_PAYMENT.getCode()); orderRepo.save(order); // 10. 关联订单号到日程记录可选方便查询 schedule.setOrderId(orderNo); scheduleRepo.save(schedule); // 11. 构造DTO返回给前端 return assembleOrderDTO(order, venue); } finally { // 12. 无论如何必须释放锁 lockService.unlock(lockKey); } } // 其他辅助方法... private BigDecimal calculateAmount(Venue venue, LocalDate date, Integer timeSlot) { BigDecimal basePrice venue.getPricePerHour(); // 简单示例周末价格上浮20% DayOfWeek dayOfWeek date.getDayOfWeek(); if (dayOfWeek DayOfWeek.SATURDAY || dayOfWeek DayOfWeek.SUNDAY) { basePrice basePrice.multiply(new BigDecimal(1.2)); } // 晚上黄金时段溢价 if (timeSlot 18 timeSlot 22) { // 假设18-22点为黄金时段 basePrice basePrice.multiply(new BigDecimal(1.5)); } return basePrice.setScale(2, RoundingMode.HALF_UP); } }代码要点解析事务边界Transactional注解在方法上意味着从方法开始到结束数据库操作在一个事务内。如果中途抛出异常所有数据库修改都会回滚。这对于“锁定场地”和“创建订单”需要原子性完成的场景至关重要。分布式锁我们使用了Redis分布式锁作为第一道防线防止大量请求同时穿透到数据库。锁的key精确到具体的场地和时段。乐观锁更新scheduleRepo.lockSchedule方法对应一个Query注解的更新操作其SQL类似于上文提到的UPDATE ... WHERE id? AND status0。通过返回值判断是否更新成功。订单号生成切忌使用数据库自增ID或简单的时间戳作为订单号。推荐使用雪花算法Snowflake它能生成全局唯一、趋势递增、且包含时间信息的ID。可以直接使用Hutool工具包里的IdUtil.getSnowflake。金额计算抽离成独立方法方便未来扩展更复杂的计费规则如会员等级折扣、优惠券、打包套餐等。4.3 支付集成与回调处理支付是另一个核心且易错的环节。以微信支付为例流程如下用户在前端确认订单点击支付。后端调用微信支付统一下单API传入订单号、金额、描述等信息获取prepay_id。后端将必要的参数如appId,timeStamp,nonceStr,package,signType,paySign组装好返回给前端。前端调起微信支付控件。用户支付成功或失败后微信服务器会异步通知回调我们的服务器。我们的回调接口需要验证签名、处理业务更新订单状态、更新场地日程状态、返回成功响应给微信。回调接口的注意事项坑点幂等性微信可能会多次回调。我们的处理逻辑必须保证即使收到重复的回调通知对订单状态的处理也是幂等的即多次处理结果一致。可以在处理前先根据订单号查询当前状态如果已是“已支付”则直接返回成功不做任何更新。异步与性能回调处理中更新订单、更新场地状态、可能还要发短信通知用户这些操作可能比较耗时。务必先返回成功响应如xmlreturn_code![CDATA[SUCCESS]]/return_code/return_msg/xml给微信然后再异步执行自己的业务逻辑。否则微信会认为通知失败反复回调。签名验证一定要严格按照微信的文档验证回调参数的签名防止伪造请求。日志记录完整记录回调的原始参数和处理结果这是排查线上支付问题的唯一依据。RestController RequestMapping(/api/payment) Slf4j public class PaymentCallbackController { PostMapping(/wx/notify) public String wxPayNotify(HttpServletRequest request) { // 1. 读取回调XML数据 String xmlData readRequestBody(request); log.info(收到微信支付回调{}, xmlData); // 2. 解析XML验证签名此处省略具体解析和验签代码需使用微信支付SDK MapString, String notifyMap parseAndVerifySign(xmlData); String orderNo notifyMap.get(out_trade_no); String transactionId notifyMap.get(transaction_id); // 3. 处理订单注意幂等性 try { paymentService.handlePaidSuccess(orderNo, transactionId); } catch (Exception e) { log.error(处理支付成功回调失败orderNo: {}, orderNo, e); // 即使业务处理失败也要返回成功给微信然后通过其他方式如人工对账处理 } // 4. 返回成功XML给微信 return xmlreturn_code![CDATA[SUCCESS]]/return_codereturn_msg![CDATA[OK]]/return_msg/xml; } }4.4 定时任务清理超时未支付订单我们之前设计了venue_schedule的locked_until字段。需要一个定时任务定期将超时仍处于“锁定”状态的记录释放掉。使用Spring Boot的Scheduled注解可以轻松实现Component Slf4j RequiredArgsConstructor public class ScheduleLockCleanupJob { private final VenueScheduleRepository scheduleRepo; // 每5分钟执行一次 Scheduled(cron 0 */5 * * * ?) Transactional public void cleanupExpiredLocks() { log.info(开始清理过期的场地锁定...); LocalDateTime now LocalDateTime.now(); // 查询状态为“已锁定”且锁定时间已过的记录 ListVenueSchedule expiredSchedules scheduleRepo.findByStatusAndLockedUntilBefore( ScheduleStatus.LOCKED.getCode(), now); for (VenueSchedule schedule : expiredSchedules) { // 重置状态为“可预约”并清空锁定时间和订单号 schedule.setStatus(ScheduleStatus.AVAILABLE.getCode()); schedule.setLockedUntil(null); schedule.setOrderId(null); scheduleRepo.save(schedule); log.debug(已释放过期锁定venueId{}, date{}, slot{}, schedule.getVenueId(), schedule.getScheduleDate(), schedule.getTimeSlot()); } log.info(清理完成共处理{}条记录。, expiredSchedules.size()); } }记得在主应用类上加上EnableScheduling注解来启用定时任务。实操心得定时任务的执行频率需要权衡。太频繁如每秒会增加数据库压力太稀疏如每小时会导致场地被无效锁定太久影响用户体验。5-10分钟是一个比较合理的区间。另外在分布式部署时要小心定时任务被多个实例重复执行。可以通过数据库行锁、Redis分布式锁或者直接使用Scheduled的fixedDelay配合应用锁不推荐生产环境来避免。5. 常见问题与排查技巧实录在实际开发和部署中你会遇到各种各样的问题。这里记录几个最典型的。5.1 前端显示有场地但一点预约就提示“已约满”可能原因与排查缓存不一致如果前端场地列表用了缓存如Redis而缓存更新不及时比如管理员刚刚修改了场地状态就会导致显示和实际不一致。解决在管理员修改场地信息后主动清除或更新对应的缓存。并发冲突这是最常见的原因。A和B几乎同时看到“可预约”A点击稍快系统锁定了场地。B紧接着点击由于乐观锁更新失败或Redis锁没抢到返回失败。排查查看venue_schedule表对应记录的状态变化日志以及应用日志中关于乐观锁更新返回0的记录。优化前端可以在点击预约按钮后立即禁用并给予“处理中”提示减少用户重复点击后端可以适当延长分布式锁的等待时间tryLock的waitTime。定时任务延迟锁定状态因支付超时本应被释放但定时任务由于某种原因服务器时间不准、任务被阻塞没有及时执行。排查检查定时任务日志确认其是否按计划执行。检查服务器系统时间。5.2 支付成功后场地状态还是“已锁定”订单状态是“待支付”这是典型的支付回调处理故障。网络问题微信的回调请求没有到达你的服务器或者到达了但你的服务器处理超时/出错微信会重试但重试也可能失败。排查第一件事是查支付回调接口的访问日志。如果没有收到任何回调请求问题可能在微信侧或网络链路上。如果收到了看处理日志。代码Bug回调接口代码有异常如签名验证失败、数据库更新异常等。排查仔细检查回调处理代码的日志特别是异常堆栈。确保数据库连接正常SQL执行无误。幂等性处理不当第一次回调处理了一半比如更新了订单状态然后异常了。微信第二次回调时你的代码因为订单状态已不是“待支付”而直接跳过导致场地状态没更新。解决回调处理逻辑必须是事务性的并且要先更新场地状态再更新订单状态。或者在同一个事务内完成如果失败就整体回滚等待微信下次回调。5.3 数据库连接池耗尽HikariCP - Connection is not available在高并发预约场景下这是一个危险信号。慢SQL某个查询或更新操作太慢导致连接被长时间占用。排查开启JPA的show-sql或者使用Druid连接池的监控功能找出执行时间长的SQL。优化索引比如venue_schedule表上status和locked_until的联合索引对清理任务很有帮助检查是否有多表关联查询没加索引。事务时间过长在Transactional方法里进行了远程调用如发短信、调支付接口这些IO操作会拖长事务占用连接。解决将非核心的、可异步的操作移到事务外。例如支付成功后发短信通知可以在更新完订单状态、提交事务后通过消息队列或Async异步执行。连接池配置过小默认的HikariCP配置可能不适合你的并发量。调整在application.yml中适当增加最大连接数。spring: datasource: hikari: maximum-pool-size: 20 # 根据实际压力调整 connection-timeout: 30000 # 连接超时时间5.4 关于“说明文档、LW、PPT”的毕业设计建议很多毕设源码包附带这些但质量参差不齐。你应该自己动手产出这才是价值的体现。说明文档README.md / 部署文档不要写废话。应该包含项目简介和功能列表。本地开发环境搭建步骤JDK版本、MySQL版本、如何导入数据库脚本、如何修改配置文件、如何启动项目。越详细越好最好能让你室友按步骤也能跑起来。关键配置说明支付配置、短信配置等敏感信息如何替换。常见问题QA把你开发中遇到的问题和解决方法写进去。论文LW切忌直接复制代码。论文的重点是阐述你的设计思路、技术选型依据、解决的关键问题如并发控制以及系统测试。画出系统的用例图、E-R图、核心模块的流程图或时序图如预约时序图、支付回调时序图。对核心算法或解决方案如防超卖机制进行重点论述。测试部分要写清楚测试用例功能测试、压力测试和结果。答辩PPT提炼精华图文并茂。结构可以这样首页题目、姓名、学号。项目背景与意义为什么做这个解决了什么痛点。系统功能演示录个GIF或截图比干讲强一百倍。系统架构与技术栈重点展示你的技术视野。核心模块与难点解决方案重中之重详细讲你的数据库设计如何防超卖支付回调如何保证一致性。系统测试与结果。总结与展望。记住答辩老师想看到的不是你做了一个多酷的系统而是你是否真正理解了背后的技术是否具备解决实际问题的能力。把上述任何一个技术点讲透你的毕设成绩就不会差。最后这个项目代码只是一个起点。你可以在此基础上继续深化引入Spring Security做更精细的权限控制使用Spring Cache缓存热门场地信息用Quartz做更强大的定时任务调度甚至拆分成微服务。但无论如何先把当前这个单体的、基于SpringBoot和MySQL的版本做扎实、做稳定这其中的思考和实践经验将是你求职简历上非常扎实的一笔。本文还有配套的精品资源点击获取 SpringBoot+MySQL实战：构建高并发羽毛球馆预约系统，详解防超卖与支付回调
简介在Web应用开发领域SpringBoot作为Java生态中广受欢迎的框架以其“约定大于配置”的理念极大地简化了企业级应用的开发与部署流程。其核心原理在于通过自动配置和起步依赖快速整合Web、数据访问、安全等模块显著提升开发效率。结合MySQL这一成熟的关系型数据库能够为需要强事务一致性和复杂查询的业务系统提供稳定可靠的数据存储方案。这种技术组合在构建具备真实业务价值的应用时尤为重要例如在线预约系统。这类系统面临的核心技术挑战之一便是高并发下的资源竞争问题即“超卖”现象。通过合理的数据库表设计如引入状态字段和唯一约束并结合乐观锁或分布式锁等并发控制机制可以有效保障数据的一致性。支付集成则是另一个关键环节需要处理好异步回调、幂等性和事务完整性以确保资金流与业务状态的同步。本文将以一个典型的羽毛球馆在线预约系统为具体案例深入剖析如何使用SpringBoot和MySQL实现从用户预约、并发控制到支付集成的完整闭环为开发者提供一个可落地的、涵盖核心业务逻辑与典型技术难点的实战参考。1. 项目概述从“交作业”到“练真功”的蜕变又到了一年一度的毕业季对于计算机相关专业的同学来说最头疼的莫过于那个绕不开的“毕业设计”。我见过太多同学面对这个任务时第一反应就是去网上搜“XXX系统源码”找到一个能跑起来的压缩包改改界面、修修Bug就匆匆提交了。如果今天你搜到的是“java羽毛球馆在线预约系统源代码springbootmysql说明文档LWPPT”并且点进了这篇文章那么恭喜你你找对地方了。但我的目的不是给你一个现成的、改改就能交差的“作业”而是想和你一起把这个看似简单的“羽毛球馆预约系统”当作一个完整的、真实的、可上线的商业项目来剖析和构建。为什么是羽毛球馆因为它太典型了。它涵盖了用户端会员预约、查看场地、管理端场地管理、订单处理、支付、定时任务清理超时未支付订单、甚至简单的数据分析热门时段统计等核心模块。麻雀虽小五脏俱全。用SpringBoot MySQL这套经典组合来实现它不仅能让你顺利毕业更能让你把学校里学的Java Web、数据库、前后端交互这些知识真正串起来形成项目经验。这篇文章我会以一个“过来人”兼项目实战者的角度带你从零开始深入这个项目的每一个技术细节和业务逻辑让你知其然更知其所以然。无论你是正在为毕设发愁的同学还是想找一个SpringBoot练手项目的开发者这篇文章都将是一份详尽的“避坑指南”和“实战手册”。2. 项目整体设计与架构选型2.1 为什么是SpringBoot MySQL看到这个技术栈你可能觉得老生常谈。但经典之所以成为经典是因为在大多数场景下它是最优解。对于毕业设计或者中小型创业项目初期选择技术栈的核心原则是成熟、稳定、社区丰富、开发效率高。SpringBoot完美契合了这些要求。它通过“约定大于配置”的理念极大地简化了Spring应用的初始搭建和开发过程。你不用再被繁琐的XML配置和依赖冲突折磨一个SpringBootApplication注解就能启动一个Web服务器。内嵌的Tomcat让你无需单独部署War包spring-boot-starter-*系列依赖能让你像搭积木一样引入数据访问、安全、缓存等功能。对于羽毛球馆预约系统来说我们可能用到的spring-boot-starter-webWeb开发、spring-boot-starter-data-jpa或mybatis-spring-boot-starter数据持久层、spring-boot-starter-security安全控制等都能轻松集成。MySQL作为最流行的开源关系型数据库其优势在于事务的ACID特性、完善的SQL支持以及海量的实践案例。预约系统的核心数据如用户信息、场地信息、订单记录都是强关系型数据需要保证数据的一致性和完整性例如一个场地在同一时间段只能被一个有效订单锁定。MySQL的事务机制和行级锁能很好地支持这一点。虽然有人会说“用MongoDB存JSON更灵活”但对于业务逻辑清晰、表结构固定的系统关系型数据库在复杂查询和事务处理上的优势是不可替代的。注意很多同学在毕设中为了“炫技”盲目引入Redis、RabbitMQ、Elasticsearch等中间件结果项目核心功能一塌糊涂中间件也只是简单配置毫无实际应用场景。这是大忌。我们的原则是如无必要勿增实体。在本系统一期完全可以只用SpringBoot和MySQL。如果后期真有性能瓶颈比如热门场地秒杀再考虑引入缓存和队列。2.2 核心业务模块拆解一个完整的在线预约系统绝不仅仅是一个“增删改查”CRUD。我们需要从用户和管理员两个视角来拆解功能。用户侧核心流程注册/登录支持手机号验证码或密码登录。这里涉及短信服务集成如阿里云、腾讯云SMS。场地浏览与查询按日期、时段、场地类型如室内/室外筛选可用场地。这里是业务逻辑的起点查询的效率和准确性是关键。预约下单选择场地、时段确认价格生成订单。这里的核心并发问题是“超卖”如何确保多个用户同时预约同一时段同一场地时只有一个成功。支付集成微信支付或支付宝。订单状态需与支付回调紧密联动未支付、已支付、已取消、已完成。个人中心查看我的订单历史、待支付、已预约、取消预约需考虑退款规则、个人信息管理。管理侧核心功能场地管理CRUD场地信息名称、类型、图片、介绍、不同时段的定价策略。定价策略可以很灵活比如工作日/周末价格不同黄金时段晚上价格上浮。订单管理查看所有订单处理退款申请手动调整订单状态。用户管理查看注册用户禁用违规账号。数据统计简单的仪表盘展示每日/每月的预约数量、营收情况、热门场地排行。这部分能为场馆运营者提供决策支持。系统设置如可预约的日期范围例如只能预约未来7天的场地、每个时段时长如1小时/节、自动取消未支付订单的时限如15分钟。2.3 技术架构图与数据流虽然我们不画复杂的架构图但在脑子里要有清晰的层次概念。一个典型的SpringBoot应用会采用分层架构控制层Controller接收HTTP请求进行参数校验推荐使用Valid注解调用服务层返回JSON响应。例如BookingController会有/api/booking/create接口。服务层Service核心业务逻辑所在地。例如BookingServiceImpl中的createOrder方法会包含检查场地可用性、生成订单号、计算金额、保存订单、可能调用支付接口等一连串操作。事务Transactional通常在这一层声明以保证业务操作的原子性。数据持久层Repository/Mapper负责与数据库交互。如果使用Spring Data JPA就是继承JpaRepository的接口如果使用MyBatis就是编写Mapper XML文件。这里定义数据的增删改查。实体层Entity/Domain与数据库表映射的Java对象。使用JPA时常用Entity注解。数据流可以这样理解用户点击“预约” - 前端调用BookingController.create()- 控制器校验参数后调用BookingService.createOrder()- 服务层内调用VenueRepository.findById()检查场地、BookingRepository.save()保存订单 - 服务层调用PaymentService发起支付 - 将支付所需信息返回给前端 - 前端引导用户完成支付。3. 核心细节解析与实操要点3.1 数据库设计如何避免“超卖”这是本系统的技术核心难点。设计不当就会出现“一房多卖”的尴尬局面。我们来设计核心表1. 场地表venueCREATE TABLE venue ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键, name varchar(100) NOT NULL COMMENT 场地名称如1号场, type tinyint(4) NOT NULL COMMENT 类型1:室内 2:室外, description text COMMENT 描述, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1:可用 0:禁用, price_per_hour decimal(10,2) NOT NULL COMMENT 基础单价元/小时, images varchar(500) DEFAULT NULL COMMENT 图片URL多个用逗号分隔, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT场地信息表;2. 场地日程表venue_schedule这是关键表。我们不直接锁“场地”而是锁“场地的某个时间段”。很多初学者设计时只在订单表里记录场地ID和开始结束时间查询可用性时需要遍历所有订单进行时间冲突判断效率低且在高并发下容易出错。CREATE TABLE venue_schedule ( id bigint(20) NOT NULL AUTO_INCREMENT, venue_id bigint(20) NOT NULL COMMENT 场地ID, schedule_date date NOT NULL COMMENT 日程日期, time_slot tinyint(4) NOT NULL COMMENT 时段编号如1代表9:00-10:00, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态0:可预约 1:已锁定 2:已预约, locked_until datetime DEFAULT NULL COMMENT 锁定截止时间用于支付超时释放, order_id varchar(32) DEFAULT NULL COMMENT 关联的订单号, PRIMARY KEY (id), UNIQUE KEY uk_venue_date_slot (venue_id,schedule_date,time_slot), KEY idx_status (status), CONSTRAINT fk_schedule_venue FOREIGN KEY (venue_id) REFERENCES venue (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT场地日程表;uk_venue_date_slot唯一索引确保同一个场地、同一天、同一个时段在数据库层面只有一条记录这是防止重复插入的第一道屏障。status字段0可预约1已锁定用户正在支付2已预约支付成功。通过状态机管理生命周期。locked_until字段用户提交订单后先将状态改为1已锁定并设置一个过期时间如当前时间15分钟。需要一个后台定时任务定期扫描状态为1且locked_until NOW()的记录将其状态重置为0。这解决了用户下单后不支付导致场地长期被占的问题。3. 订单表booking_orderCREATE TABLE booking_order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号唯一业务生成, user_id bigint(20) NOT NULL COMMENT 用户ID, venue_id bigint(20) NOT NULL COMMENT 场地ID, schedule_date date NOT NULL COMMENT 预约日期, time_slot tinyint(4) NOT NULL COMMENT 时段, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 订单状态0:待支付 1:已支付 2:已取消 3:已完成, pay_time datetime DEFAULT NULL COMMENT 支付时间, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_status (status), CONSTRAINT fk_order_venue FOREIGN KEY (venue_id) REFERENCES venue (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT预约订单表;实操心得数据库设计时时间字段尽量使用datetime或timestamp并明确时区问题。金额使用decimal类型避免浮点数精度丢失。所有外键字段都要建立索引如venue_id,user_id。update_time的自动更新在排查数据问题时非常有用。3.2 高并发下的预约锁悲观锁 vs 乐观锁当两个用户同时点击预约同一个时段时如何保证只有一个成功这就是并发控制。方案一悲观锁Pessimistic Lock在查询并修改venue_schedule记录时使用SELECT ... FOR UPDATE。这会在事务中给这条记录加上行锁其他事务必须等待。Transactional public Order createOrder(Long venueId, LocalDate date, Integer timeSlot, Long userId) { // 1. 悲观锁查询 VenueSchedule schedule venueScheduleRepository.findByVenueIdAndDateAndSlotForUpdate(venueId, date, timeSlot); if (schedule null || schedule.getStatus() ! 0) { throw new BusinessException(该时段不可预约); } // 2. 更新状态为锁定 schedule.setStatus(1); schedule.setLockedUntil(LocalDateTime.now().plusMinutes(15)); venueScheduleRepository.save(schedule); // 3. 创建订单... }这种方法简单直接在并发不高时很有效。但缺点是如果事务时间长会长时间锁住记录影响吞吐量。方案二乐观锁Optimistic Lock给venue_schedule表增加一个版本号字段version或使用更新时间update_time。更新时带上版本号作为条件。UPDATE venue_schedule SET status 1, locked_until ?, version version 1 WHERE id ? AND status 0 AND version ?;如果更新返回的影响行数为0说明在此期间记录已被别人修改本次操作失败需要提示用户“预约失败请重试”。Spring Data JPA可以通过Version注解轻松实现。方案三分布式锁Redis在分布式部署环境下数据库行锁可能不够用。可以使用Redis的SETNX或Redisson客户端实现一个分布式锁key可以是lock:venue:{venueId}:{date}:{timeSlot}在创建订单前先获取锁获取成功后再进行后续数据库操作操作完成后释放锁。我的选择与建议对于毕业设计或初期项目推荐使用“乐观锁”。因为它实现简单在并发冲突不极端的情况下性能更好。我们可以在服务层捕获更新失败异常然后返回友好的错误信息给前端前端可以提示用户“手速慢了请重新选择”。这比让用户长时间等待数据库行锁释放体验更好。在实际编码中结合venue_schedule表的唯一索引可以做到双重保障。4. 实操过程与核心环节实现4.1 项目初始化与基础框架搭建我们使用Spring Initializrhttps://start.spring.io/来快速生成项目骨架。选择Project: Maven Project (更通用)Language: JavaSpring Boot: 选择2.7.x或3.x的稳定版本注意3.x需要Java 17Dependencies:Spring Web: 构建Web应用Spring Data JPA: 数据持久化这里以JPA为例你也可以选MyBatisMySQL Driver: 连接MySQLLombok: 简化POJO代码强烈推荐Validation: 参数校验生成项目后在application.yml中配置数据库和JPAspring: datasource: url: jdbc:mysql://localhost:3306/booking_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver jpa: hibernate: ddl-auto: update # 项目初期可以用update自动建表生产环境务必改为validate或none show-sql: true # 开发时开启方便看生成的SQL properties: hibernate: dialect: org.hibernate.dialect.MySQL8Dialect format_sql: true4.2 核心业务创建预约订单服务实现让我们聚焦最核心的BookingService.createOrder方法。这里会融合数据库设计、并发控制和业务逻辑。Service Slf4j RequiredArgsConstructor // Lombok注解为final字段生成构造函数 public class BookingServiceImpl implements BookingService { private final VenueScheduleRepository scheduleRepo; private final BookingOrderRepository orderRepo; private final DistributedLockService lockService; // 假设我们用了Redis分布式锁 private final SnowflakeIdGenerator idGenerator; // 雪花算法生成订单号 Override Transactional(rollbackFor Exception.class) // 声明式事务异常回滚 public OrderDTO createOrder(CreateOrderRequest request) { Long venueId request.getVenueId(); LocalDate date request.getDate(); Integer timeSlot request.getTimeSlot(); Long userId AuthContext.getCurrentUserId(); // 从线程上下文获取当前用户 // 1. 基础校验场地是否存在、是否可用等 Venue venue validateVenue(venueId); // 2. 构建分布式锁的key String lockKey String.format(lock:booking:%d:%s:%d, venueId, date, timeSlot); // 3. 尝试获取锁设置锁超时时间防止死锁 boolean locked lockService.tryLock(lockKey, 10, TimeUnit.SECONDS); if (!locked) { throw new BusinessException(系统繁忙请稍后重试); } try { // 4. 查询日程记录这里可以不用FOR UPDATE因为锁已经由Redis管理 VenueSchedule schedule scheduleRepo.findByVenueIdAndScheduleDateAndTimeSlot(venueId, date, timeSlot) .orElseThrow(() - new BusinessException(该时段不存在)); // 5. 检查状态是否可预约 if (schedule.getStatus() ! ScheduleStatus.AVAILABLE.getCode()) { throw new BusinessException(该时段已被预约); } // 6. 乐观锁更新状态 int updateCount scheduleRepo.lockSchedule(schedule.getId(), ScheduleStatus.LOCKED.getCode(), LocalDateTime.now().plusMinutes(15)); if (updateCount 0) { // 乐观锁更新失败说明状态已被其他请求改变 throw new BusinessException(预约失败请重新选择); } // 7. 生成订单号使用雪花算法避免重复和可猜测 String orderNo idGenerator.nextIdStr(); // 8. 计算金额这里可以扩展复杂的计价规则如会员折扣、时段溢价 BigDecimal amount calculateAmount(venue, date, timeSlot); // 9. 创建订单实体并保存 BookingOrder order new BookingOrder(); order.setOrderNo(orderNo); order.setUserId(userId); order.setVenueId(venueId); order.setScheduleDate(date); order.setTimeSlot(timeSlot); order.setTotalAmount(amount); order.setStatus(OrderStatus.PENDING_PAYMENT.getCode()); orderRepo.save(order); // 10. 关联订单号到日程记录可选方便查询 schedule.setOrderId(orderNo); scheduleRepo.save(schedule); // 11. 构造DTO返回给前端 return assembleOrderDTO(order, venue); } finally { // 12. 无论如何必须释放锁 lockService.unlock(lockKey); } } // 其他辅助方法... private BigDecimal calculateAmount(Venue venue, LocalDate date, Integer timeSlot) { BigDecimal basePrice venue.getPricePerHour(); // 简单示例周末价格上浮20% DayOfWeek dayOfWeek date.getDayOfWeek(); if (dayOfWeek DayOfWeek.SATURDAY || dayOfWeek DayOfWeek.SUNDAY) { basePrice basePrice.multiply(new BigDecimal(1.2)); } // 晚上黄金时段溢价 if (timeSlot 18 timeSlot 22) { // 假设18-22点为黄金时段 basePrice basePrice.multiply(new BigDecimal(1.5)); } return basePrice.setScale(2, RoundingMode.HALF_UP); } }代码要点解析事务边界Transactional注解在方法上意味着从方法开始到结束数据库操作在一个事务内。如果中途抛出异常所有数据库修改都会回滚。这对于“锁定场地”和“创建订单”需要原子性完成的场景至关重要。分布式锁我们使用了Redis分布式锁作为第一道防线防止大量请求同时穿透到数据库。锁的key精确到具体的场地和时段。乐观锁更新scheduleRepo.lockSchedule方法对应一个Query注解的更新操作其SQL类似于上文提到的UPDATE ... WHERE id? AND status0。通过返回值判断是否更新成功。订单号生成切忌使用数据库自增ID或简单的时间戳作为订单号。推荐使用雪花算法Snowflake它能生成全局唯一、趋势递增、且包含时间信息的ID。可以直接使用Hutool工具包里的IdUtil.getSnowflake。金额计算抽离成独立方法方便未来扩展更复杂的计费规则如会员等级折扣、优惠券、打包套餐等。4.3 支付集成与回调处理支付是另一个核心且易错的环节。以微信支付为例流程如下用户在前端确认订单点击支付。后端调用微信支付统一下单API传入订单号、金额、描述等信息获取prepay_id。后端将必要的参数如appId,timeStamp,nonceStr,package,signType,paySign组装好返回给前端。前端调起微信支付控件。用户支付成功或失败后微信服务器会异步通知回调我们的服务器。我们的回调接口需要验证签名、处理业务更新订单状态、更新场地日程状态、返回成功响应给微信。回调接口的注意事项坑点幂等性微信可能会多次回调。我们的处理逻辑必须保证即使收到重复的回调通知对订单状态的处理也是幂等的即多次处理结果一致。可以在处理前先根据订单号查询当前状态如果已是“已支付”则直接返回成功不做任何更新。异步与性能回调处理中更新订单、更新场地状态、可能还要发短信通知用户这些操作可能比较耗时。务必先返回成功响应如xmlreturn_code![CDATA[SUCCESS]]/return_code/return_msg/xml给微信然后再异步执行自己的业务逻辑。否则微信会认为通知失败反复回调。签名验证一定要严格按照微信的文档验证回调参数的签名防止伪造请求。日志记录完整记录回调的原始参数和处理结果这是排查线上支付问题的唯一依据。RestController RequestMapping(/api/payment) Slf4j public class PaymentCallbackController { PostMapping(/wx/notify) public String wxPayNotify(HttpServletRequest request) { // 1. 读取回调XML数据 String xmlData readRequestBody(request); log.info(收到微信支付回调{}, xmlData); // 2. 解析XML验证签名此处省略具体解析和验签代码需使用微信支付SDK MapString, String notifyMap parseAndVerifySign(xmlData); String orderNo notifyMap.get(out_trade_no); String transactionId notifyMap.get(transaction_id); // 3. 处理订单注意幂等性 try { paymentService.handlePaidSuccess(orderNo, transactionId); } catch (Exception e) { log.error(处理支付成功回调失败orderNo: {}, orderNo, e); // 即使业务处理失败也要返回成功给微信然后通过其他方式如人工对账处理 } // 4. 返回成功XML给微信 return xmlreturn_code![CDATA[SUCCESS]]/return_codereturn_msg![CDATA[OK]]/return_msg/xml; } }4.4 定时任务清理超时未支付订单我们之前设计了venue_schedule的locked_until字段。需要一个定时任务定期将超时仍处于“锁定”状态的记录释放掉。使用Spring Boot的Scheduled注解可以轻松实现Component Slf4j RequiredArgsConstructor public class ScheduleLockCleanupJob { private final VenueScheduleRepository scheduleRepo; // 每5分钟执行一次 Scheduled(cron 0 */5 * * * ?) Transactional public void cleanupExpiredLocks() { log.info(开始清理过期的场地锁定...); LocalDateTime now LocalDateTime.now(); // 查询状态为“已锁定”且锁定时间已过的记录 ListVenueSchedule expiredSchedules scheduleRepo.findByStatusAndLockedUntilBefore( ScheduleStatus.LOCKED.getCode(), now); for (VenueSchedule schedule : expiredSchedules) { // 重置状态为“可预约”并清空锁定时间和订单号 schedule.setStatus(ScheduleStatus.AVAILABLE.getCode()); schedule.setLockedUntil(null); schedule.setOrderId(null); scheduleRepo.save(schedule); log.debug(已释放过期锁定venueId{}, date{}, slot{}, schedule.getVenueId(), schedule.getScheduleDate(), schedule.getTimeSlot()); } log.info(清理完成共处理{}条记录。, expiredSchedules.size()); } }记得在主应用类上加上EnableScheduling注解来启用定时任务。实操心得定时任务的执行频率需要权衡。太频繁如每秒会增加数据库压力太稀疏如每小时会导致场地被无效锁定太久影响用户体验。5-10分钟是一个比较合理的区间。另外在分布式部署时要小心定时任务被多个实例重复执行。可以通过数据库行锁、Redis分布式锁或者直接使用Scheduled的fixedDelay配合应用锁不推荐生产环境来避免。5. 常见问题与排查技巧实录在实际开发和部署中你会遇到各种各样的问题。这里记录几个最典型的。5.1 前端显示有场地但一点预约就提示“已约满”可能原因与排查缓存不一致如果前端场地列表用了缓存如Redis而缓存更新不及时比如管理员刚刚修改了场地状态就会导致显示和实际不一致。解决在管理员修改场地信息后主动清除或更新对应的缓存。并发冲突这是最常见的原因。A和B几乎同时看到“可预约”A点击稍快系统锁定了场地。B紧接着点击由于乐观锁更新失败或Redis锁没抢到返回失败。排查查看venue_schedule表对应记录的状态变化日志以及应用日志中关于乐观锁更新返回0的记录。优化前端可以在点击预约按钮后立即禁用并给予“处理中”提示减少用户重复点击后端可以适当延长分布式锁的等待时间tryLock的waitTime。定时任务延迟锁定状态因支付超时本应被释放但定时任务由于某种原因服务器时间不准、任务被阻塞没有及时执行。排查检查定时任务日志确认其是否按计划执行。检查服务器系统时间。5.2 支付成功后场地状态还是“已锁定”订单状态是“待支付”这是典型的支付回调处理故障。网络问题微信的回调请求没有到达你的服务器或者到达了但你的服务器处理超时/出错微信会重试但重试也可能失败。排查第一件事是查支付回调接口的访问日志。如果没有收到任何回调请求问题可能在微信侧或网络链路上。如果收到了看处理日志。代码Bug回调接口代码有异常如签名验证失败、数据库更新异常等。排查仔细检查回调处理代码的日志特别是异常堆栈。确保数据库连接正常SQL执行无误。幂等性处理不当第一次回调处理了一半比如更新了订单状态然后异常了。微信第二次回调时你的代码因为订单状态已不是“待支付”而直接跳过导致场地状态没更新。解决回调处理逻辑必须是事务性的并且要先更新场地状态再更新订单状态。或者在同一个事务内完成如果失败就整体回滚等待微信下次回调。5.3 数据库连接池耗尽HikariCP - Connection is not available在高并发预约场景下这是一个危险信号。慢SQL某个查询或更新操作太慢导致连接被长时间占用。排查开启JPA的show-sql或者使用Druid连接池的监控功能找出执行时间长的SQL。优化索引比如venue_schedule表上status和locked_until的联合索引对清理任务很有帮助检查是否有多表关联查询没加索引。事务时间过长在Transactional方法里进行了远程调用如发短信、调支付接口这些IO操作会拖长事务占用连接。解决将非核心的、可异步的操作移到事务外。例如支付成功后发短信通知可以在更新完订单状态、提交事务后通过消息队列或Async异步执行。连接池配置过小默认的HikariCP配置可能不适合你的并发量。调整在application.yml中适当增加最大连接数。spring: datasource: hikari: maximum-pool-size: 20 # 根据实际压力调整 connection-timeout: 30000 # 连接超时时间5.4 关于“说明文档、LW、PPT”的毕业设计建议很多毕设源码包附带这些但质量参差不齐。你应该自己动手产出这才是价值的体现。说明文档README.md / 部署文档不要写废话。应该包含项目简介和功能列表。本地开发环境搭建步骤JDK版本、MySQL版本、如何导入数据库脚本、如何修改配置文件、如何启动项目。越详细越好最好能让你室友按步骤也能跑起来。关键配置说明支付配置、短信配置等敏感信息如何替换。常见问题QA把你开发中遇到的问题和解决方法写进去。论文LW切忌直接复制代码。论文的重点是阐述你的设计思路、技术选型依据、解决的关键问题如并发控制以及系统测试。画出系统的用例图、E-R图、核心模块的流程图或时序图如预约时序图、支付回调时序图。对核心算法或解决方案如防超卖机制进行重点论述。测试部分要写清楚测试用例功能测试、压力测试和结果。答辩PPT提炼精华图文并茂。结构可以这样首页题目、姓名、学号。项目背景与意义为什么做这个解决了什么痛点。系统功能演示录个GIF或截图比干讲强一百倍。系统架构与技术栈重点展示你的技术视野。核心模块与难点解决方案重中之重详细讲你的数据库设计如何防超卖支付回调如何保证一致性。系统测试与结果。总结与展望。记住答辩老师想看到的不是你做了一个多酷的系统而是你是否真正理解了背后的技术是否具备解决实际问题的能力。把上述任何一个技术点讲透你的毕设成绩就不会差。最后这个项目代码只是一个起点。你可以在此基础上继续深化引入Spring Security做更精细的权限控制使用Spring Cache缓存热门场地信息用Quartz做更强大的定时任务调度甚至拆分成微服务。但无论如何先把当前这个单体的、基于SpringBoot和MySQL的版本做扎实、做稳定这其中的思考和实践经验将是你求职简历上非常扎实的一笔。本文还有配套的精品资源点击获取