Spring Boot在线票务预订平台实战：Redis锁座、消息队列与超卖防护

简介这份资源是一篇完整的Spring Boot在线票务预订平台特麦网毕业论文文档面向计算机相关专业毕业生及需要完成类似系统设计与论文写作的开发者。论文围绕在线预订、座位选择、支付处理与电子票发放等核心功能展开采用Java语言、Spring Boot框架与MySQL数据库实现并涵盖数据加密、身份验证等安全设计。压缩包内仅含1个doc文件约7.32MB即论文正文全文包含绪论、开发工具介绍、需求分析、数据库设计与详细系统设计等章节目录结构完整可直接作为毕业设计参考模板。目前已有81人学习下载。读者可从中获取完整的系统分析思路、UML用例与流程分析、功能模块划分及数据库设计方法适合需要撰写同类论文或搭建票务预订系统的学习者借鉴。1. 从一份“毕业论文.doc”说起在线票务预订平台到底要解决什么每年毕业季基于 Spring Boot 的在线票务预订平台都是高频选题。但真正动手做过的人都知道这个题目看着简单落地时问题一堆座位怎么保证不超卖、订单超时怎么自动取消、并发下库存怎么扣减、前后端分离后接口怎么对齐。它不是一个“增删改查大作业”而是一个把 Spring Boot 全家桶串起来的综合场景——MySQL 做持久化、Redis 扛热点库存、消息队列削峰、定时任务兜底。适合谁适合已经学完 Spring Boot 基础、想用一个完整项目把知识点串起来的人也适合需要一份能跑起来、能讲清楚技术选型的毕设作者。这一章先把业务边界和技术骨架立住后面几章再一步步落到代码和参数上。2. 票务平台的技术选型为什么是 Spring Boot 加这套组合2.1 业务模型先拆清楚别急着写代码在线票务预订平台的核心实体其实不多用户、演出/场次、座位区域、座位、订单、支付记录。真正复杂的是它们之间的关系和状态流转。一个场次对应多个座位区域比如 VIP 区、普通区一个区域对应多个具体座位座位有“可售、锁定、已售”三种状态。订单从“待支付”到“已支付”再到“已核销”中间还有“已取消”和“超时关闭”。我一般会先画一张状态流转表把每个状态能触发什么动作写清楚再动手建表。很多人上来就CREATE TABLE结果写到订单模块发现状态对不上回头改表结构血泪经验。实体关键字段状态字段取值场次演出名、时间、场馆未开售/在售/售罄/已结束座位区域ID、排号、列号可售/锁定/已售订单用户ID、场次ID、金额待支付/已支付/已取消/超时关闭支付记录订单ID、流水号、金额成功/失败/退款座位状态和订单状态是两套独立的状态机但通过“锁定”这个动作耦合在一起。下单时锁座支付成功转已售超时未支付则释放回可售。这个耦合点就是后面并发问题的根源。2.2 为什么选 Spring Boot 而不是别的热搜里“springboot项目”“springboot框架介绍”常年霸榜不是没有道理。票务平台这种中等复杂度的 Web 应用Spring Boot 的优势在于起步依赖把 Web、JPA/MyBatis、Redis、消息队列的整合成本压到最低内嵌 Tomcat 让部署变成一个 jar 包的事配置外置让开发和生产环境切换不用改代码。具体到版本我建议用 Spring Boot 2.7.x。热搜里有人问“springboot版本太高”确实3.x 要求 JDK 17 起步很多学校的实验环境还停在 JDK 8 或 11强行上 3.x 会在依赖兼容上翻车。2.7.18 是 2.x 的最后一个维护版本稳定且资料多适合毕设场景。技术栈组合我一般这样定持久层MyBatis-Plus比原生 MyBatis 少写很多 XML分页插件开箱即用缓存Redis用来做座位锁和热点场次缓存消息队列RabbitMQ 或 RocketMQ用来异步处理订单超时关闭定时任务Spring 自带的Scheduled或 Quartz做兜底扫描前端Vue 或 Thymeleaf 都行毕设里前后端分离更常见提示如果学校要求必须用 JPA把 MyBatis-Plus 换掉即可业务逻辑层的代码基本不用动因为持久层接口是隔离的。2.3 项目骨架怎么搭从 IDEA 新建到跑通第一个接口热搜里“idea创建springboot项目”“idea新建springboot项目”是高频操作。我用 IDEA 的 Spring Initializr 建项目选 Maven、JDK 11、Spring Boot 2.7.18依赖勾选 Spring Web、MyBatis Framework、MySQL Driver、Spring Data Redis、Lombok。建完之后先别急着写业务把数据库连上、跑通一个健康检查接口确认环境没问题。application.yml里配置数据源和 Redisspring: datasource: url: jdbc:mysql://localhost:3306/ticket_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0 timeout: 3000ms mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: trueurl里的serverTimezone必须写否则 MySQL 8 会报时区错误。map-underscore-to-camel-case让数据库的seat_id自动映射到 Java 的seatId省掉大量Results注解。Redis 的timeout设 3000ms避免连接池卡死时请求一直挂着。写一个HealthController返回当前时间启动项目用浏览器或 curl 访问能通就说明骨架没问题。这一步看着简单但很多人跳过后面出问题时分不清是业务代码的锅还是环境的锅。3. 座位锁定与订单创建并发下不超卖的核心实现3.1 为什么数据库行锁扛不住票务场景最直觉的做法是下单时SELECT ... FOR UPDATE锁住座位行扣减库存再插订单。单机低并发下没问题但票务平台的典型场景是“开票瞬间大量用户抢同一场次的座位”。行锁会把数据库连接占满请求排队响应时间飙升严重时连接池耗尽直接雪崩。热搜里“springboot项目全局过滤器处理上传pdf文件时xss攻击”这类问题属于安全层面而超卖属于并发层面两者都是票务平台绕不开的。超卖的根因是“检查库存”和“扣减库存”不是原子操作。数据库行锁能保证原子性但代价是吞吐量。我一般用 Redis 的原子操作来做第一道闸门数据库只做最终落库。3.2 用 Redis 做座位锁SETNX 加过期时间核心思路用户选座后用SET key value NX EX命令尝试锁定座位。key 是seat:lock:{场次ID}:{座位ID}value 是用户ID或订单号EX 是过期时间比如 300 秒。设置成功说明锁到了设置失败说明被别人抢了。Service public class SeatLockService { Autowired private StringRedisTemplate redisTemplate; private static final long LOCK_EXPIRE_SECONDS 300; /** * 尝试锁定座位 * param sessionId 场次ID * param seatId 座位ID * param userId 用户ID * return true 锁定成功false 已被占用 */ public boolean tryLockSeat(Long sessionId, Long seatId, Long userId) { String key seat:lock: sessionId : seatId; String value String.valueOf(userId); Boolean success redisTemplate.opsForValue() .setIfAbsent(key, value, LOCK_EXPIRE_SECONDS, TimeUnit.SECONDS); return Boolean.TRUE.equals(success); } /** * 释放座位锁订单取消或超时时调用 */ public void releaseSeatLock(Long sessionId, Long seatId) { String key seat:lock: sessionId : seatId; redisTemplate.delete(key); } }setIfAbsent对应 Redis 的SET NX是原子操作多个线程同时调用只有一个能成功。LOCK_EXPIRE_SECONDS设 300 秒给用户留出支付时间超时后锁自动释放避免用户下单后不支付导致座位永久锁死。releaseSeatLock在订单取消或支付失败时主动调用比等过期更快释放。注意释放锁时没有校验 value 是不是当前用户严格来说应该用 Lua 脚本做“比较并删除”防止误删别人的锁。毕设场景下过期时间兜底够用但生产环境必须加校验。3.3 订单创建与超时关闭消息队列加定时任务双保险锁座成功后创建订单订单状态为“待支付”同时往消息队列发一条延迟消息延迟时间等于支付超时时间比如 15 分钟。消费者收到消息后检查订单状态如果还是“待支付”就关闭订单并释放座位锁。Service public class OrderService { Autowired private SeatLockService seatLockService; Autowired private OrderMapper orderMapper; Autowired private RabbitTemplate rabbitTemplate; private static final long PAY_TIMEOUT_MILLIS 15 * 60 * 1000; Transactional public Order createOrder(Long userId, Long sessionId, Long seatId) { // 第一步Redis 锁座 boolean locked seatLockService.tryLockSeat(sessionId, seatId, userId); if (!locked) { throw new BusinessException(座位已被占用请选择其他座位); } // 第二步落库订单 Order order new Order(); order.setUserId(userId); order.setSessionId(sessionId); order.setSeatId(seatId); order.setStatus(OrderStatus.PENDING_PAY); order.setCreateTime(new Date()); orderMapper.insert(order); // 第三步发延迟消息用于超时关闭 rabbitTemplate.convertAndSend(order.delay.exchange, order.delay, order.getId(), message - { message.getMessageProperties().setExpiration(String.valueOf(PAY_TIMEOUT_MILLIS)); return message; }); return order; } }Transactional保证订单落库的原子性但注意它管不到 Redis所以锁座和落库之间如果落库失败需要手动释放锁。实际写的时候我会在 catch 块里调releaseSeatLock。延迟消息的过期时间通过setExpiration设置RabbitMQ 的延迟队列靠死信交换机实现消息过期后进入死信队列消费者监听死信队列做关闭逻辑。光靠消息队列不够可靠消息可能丢。所以再加一个定时任务每 5 分钟扫一次数据库里创建时间超过 15 分钟且状态还是“待支付”的订单批量关闭。这就是双保险热搜里“springboot整合activemq”也是类似思路只是消息中间件换成了 ActiveMQ。Component public class OrderTimeoutTask { Autowired private OrderMapper orderMapper; Autowired private SeatLockService seatLockService; Scheduled(fixedDelay 5 * 60 * 1000) public void closeTimeoutOrders() { Date deadline new Date(System.currentTimeMillis() - 15 * 60 * 1000); ListOrder timeoutOrders orderMapper.selectTimeoutOrders(deadline); for (Order order : timeoutOrders) { order.setStatus(OrderStatus.TIMEOUT_CLOSED); orderMapper.updateById(order); seatLockService.releaseSeatLock(order.getSessionId(), order.getSeatId()); } } }fixedDelay表示上一次执行完再等 5 分钟避免任务重叠。selectTimeoutOrders的 SQL 里加LIMIT防止一次扫太多分批处理。4. 前后端分离下的接口设计与数据一致性排查4.1 接口约定统一返回体和分页参数热搜里“springboot vue前后端分离”“mybatis的分页插件的用法 springboot”是高频组合。前后端分离最容易出问题的地方是接口格式不统一前端解析起来一堆 if-else。我一般定义一个ResultT包装类所有接口都返回这个结构。Data public class ResultT { private int code; private String message; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.setCode(200); r.setMessage(success); r.setData(data); return r; } public static T ResultT fail(String message) { ResultT r new Result(); r.setCode(500); r.setMessage(message); return r; } }分页用 MyBatis-Plus 的Page对象配置分页插件后orderMapper.selectPage(page, wrapper)自动拼LIMIT。前端传pageNum和pageSize后端返回total和records。参数校验用Valid加NotNull别让脏数据进到业务层。4.2 数据一致性Redis 锁和数据库状态对不上怎么办这是票务平台最头疼的问题。Redis 锁过期了但订单还没支付座位在 Redis 里变成可锁但数据库里订单还是“待支付”。用户重新选这个座位锁成功创建了新订单结果两个订单指向同一个座位。排查思路分三步。第一看 Redis 锁的过期时间和订单超时时间是否一致不一致就统一。第二看定时任务有没有正常执行日志里搜closeTimeoutOrders。第三看释放锁的逻辑有没有在订单关闭时被调用。我一般会在释放锁的地方打日志记录场次、座位、订单号方便对账。解决方式是把“锁过期”和“订单关闭”绑定锁的过期时间略大于订单超时时间比如订单 15 分钟超时锁设 16 分钟。这样即使消息丢了定时任务在 15 分钟时关闭订单并释放锁不会出现锁先过期的情况。4.3 用日志和唯一索引兜底再好的逻辑也可能有漏网之鱼。数据库层面加一个唯一索引UNIQUE KEY uk_session_seat (session_id, seat_id, status)但 status 是“已售”时才唯一MySQL 不支持条件唯一索引。变通做法是单独建一张seat_sold表场次ID和座位ID做联合唯一索引支付成功时插入插入失败说明超卖直接回滚。CREATE TABLE seat_sold ( id BIGINT PRIMARY KEY AUTO_INCREMENT, session_id BIGINT NOT NULL, seat_id BIGINT NOT NULL, order_id BIGINT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_session_seat (session_id, seat_id) );支付回调里先INSERT INTO seat_sold捕获DuplicateKeyException有异常就说明这个座位已经被别的订单卖了当前订单标记为异常并退款。这是最后一道防线平时不触发触发就是救命。5. 避坑与常见问题那些让我熬夜的翻车现场5.1 现象项目启动报Table ticket_db.xxx doesnt exist原因MyBatis-Plus 默认把实体类名转成下划线表名比如Order转成order但order是 MySQL 关键字建表时用了反引号查询时没加导致语法错误或找不到表。解决实体类上加TableName(t_order)显式指定表名或者全局配置table-prefix: t_。我一般直接改表名为t_order、t_seat避开关键字。5.2 现象Redis 锁释放后座位还是显示“已锁定”原因释放锁的代码在事务里但事务还没提交Redis 的删除操作已经执行了。另一个请求进来锁成功读数据库发现订单还在状态对不上。解决把释放锁的操作放到事务提交之后用TransactionSynchronizationManager.registerSynchronization在afterCommit里执行。或者干脆不在事务里释放由定时任务统一处理。5.3 现象定时任务不执行原因启动类上忘了加EnableScheduling。或者任务方法所在的类没有被 Spring 管理Scheduled不生效。解决启动类加EnableScheduling任务类加Component。另外注意Scheduled默认单线程多个任务会互相阻塞配置一个TaskScheduler线程池。5.4 现象前端跨域请求被拦截原因前后端分离前端跑在 8080后端跑在 8081浏览器同源策略拦截。解决后端加全局 CORS 配置实现WebMvcConfigurer的addCorsMappings允许前端域名。别用CrossOrigin一个个加容易漏。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowCredentials(true) .maxAge(3600); } }allowedOriginPatterns用*时allowCredentials必须为 true 才生效这是 Spring 的规则。5.5 现象支付回调重复执行订单被多次处理原因支付平台回调可能重试同一个订单号回调多次。解决回调接口做幂等用订单号查支付记录已存在就直接返回成功。或者用 Redis 的SETNX对订单号加锁处理完再释放。6. 进阶技巧用压测验证你的票务平台到底能扛多少6.1 用 JMeter 模拟抢票看瓶颈在哪写完代码不代表能扛住。我一般用 JMeter 建一个线程组100 个线程循环 10 次同时请求下单接口看响应时间和错误率。重点观察三个指标Redis 的setIfAbsent耗时、数据库插入耗时、消息队列发送耗时。如果 Redis 耗时飙升说明连接池不够调大spring.redis.lettuce.pool.max-active。如果数据库插入慢看慢查询日志给t_order的user_id和create_time加索引。如果消息队列发送阻塞检查 RabbitMQ 的连接数和确认机制。6.2 用 Redis 的INFO命令看锁的情况压测过程中在 Redis 客户端执行INFO keyspace看db0的 keys 数量变化。如果锁的 key 一直增长不释放说明释放逻辑有问题。再用TTL命令看某个锁的剩余时间确认过期时间符合预期。redis-cli INFO keyspace TTL seat:lock:1001:2001 KEYS seat:lock:*KEYS命令在生产环境慎用会阻塞 Redis压测环境无所谓。正式环境用SCAN代替。6.3 一个具体技巧用 Lua 脚本做原子释放前面提到释放锁没校验 value严格做法是用 Lua 脚本把“比较 value”和“删除 key”合成原子操作。private static final String RELEASE_LOCK_LUA if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; public boolean releaseLockSafely(String key, String value) { DefaultRedisScriptLong script new DefaultRedisScript(); script.setScriptText(RELEASE_LOCK_LUA); script.setResultType(Long.class); Long result redisTemplate.execute(script, Collections.singletonList(key), value); return result ! null result 0; }KEYS[1]是锁的 keyARGV[1]是当前用户ID。脚本先get再比较相等才del整个过程在 Redis 里原子执行。这样即使锁过期后被别人抢到当前线程也不会误删别人的锁。6.4 验证方法对账脚本最后写一个对账脚本每天跑一次检查 Redis 里锁定的座位和数据库里“待支付”订单是否一一对应。不一致的记录输出到日志人工排查。脚本逻辑很简单遍历seat:lock:*的 key解析出场次和座位查数据库有没有对应的待支付订单再反向查数据库待支付订单看 Redis 里有没有对应的锁。Component public class ReconciliationTask { Autowired private StringRedisTemplate redisTemplate; Autowired private OrderMapper orderMapper; Scheduled(cron 0 0 3 * * ?) public void reconcile() { SetString lockKeys redisTemplate.keys(seat:lock:*); for (String key : lockKeys) { String[] parts key.split(:); Long sessionId Long.valueOf(parts[2]); Long seatId Long.valueOf(parts[3]); Order order orderMapper.selectPendingBySessionAndSeat(sessionId, seatId); if (order null) { // Redis 有锁但数据库没有待支付订单说明锁是脏数据 redisTemplate.delete(key); } } } }cron表达式0 0 3 * * ?表示每天凌晨 3 点执行。keys命令在数据量大时慢可以改成scan。这个脚本不解决实时问题但能帮你发现系统性的不一致比出了问题再翻日志强。我做这类项目最大的习惯是先把状态流转和对账逻辑想清楚再写业务代码。票务平台的坑大多不在代码本身而在状态和时序。希望帮到你。本文还有配套的精品资源点击获取