尧图网站建设 
简介本资源为基于Java的大剧院订票选座管理系统毕业设计完整资料包面向计算机相关专业需要完成毕业设计或课程设计的学生以及希望积累B/S架构项目实战经验的开发者。系统采用Java语言与MySQL数据库分为前台与后台前台支持会员注册登录、浏览戏剧戏曲歌舞舞蹈音乐曲艺杂技马戏等节目、在线预订生成订单及个人信息维护后台由管理员审核订单、管理节目分类与用户信息、发布公告推送。压缩包共1619个文件约78.06MB涵盖130个java源码、129个class、96个vue组件、86个html页面、88个css样式、306个js脚本以及sql建库脚本、xml配置、mp4演示视频和说明文档前端资源含svg、gif、png、jpg等图片素材结构完整便于二次开发。目前已有179人学习下载适合需要完整赛题方案、可运行源码、数据库脚本与操作录屏的读者参考帮助快速理解订票选座业务逻辑与前后端交互流程。1. 从一张剧院座位图说起Java 订票选座系统到底在解决什么问题很多人第一次做「基于 Java 的大剧院订票选座管理系统」时脑子里想的是 CRUD用户表、演出表、订单表增删改查一套就完事。真上手才发现最难的从来不是增删改查而是选座——同一排相邻两个座位怎么算、已经被锁的座位怎么实时同步、两个人同时点同一个座位谁赢。这才是这个毕业设计真正的技术含量所在也是答辩老师最爱追问的地方。这个系统面向的场景很具体大剧院有若干演出场次每个场次对应一张座位图观众登录后挑场次、点座位、下单支付后台管理员维护演出和座位状态。它适合正在做 Java 方向毕业设计的同学也适合想练手一个「有并发、有状态、有前后端交互」的完整项目的开发者。数据库设计、座位状态机、并发锁座这三块是决定这个项目能不能拿高分、能不能真正跑起来的关键。下面我按自己带过几届毕设的经验把选型、建库、锁座、避坑一条条讲清楚。2. 技术选型与数据库设计为什么用 Spring Boot MyBatis MySQL2.1 技术栈怎么选才不给自己挖坑毕业设计最忌讳技术栈堆得太花。我见过有人上来就微服务、Redis 集群、消息队列全套结果连座位状态都没跑通答辩时被问「你这个分布式锁解决什么问题」直接卡壳。常见且稳妥的做法是Spring Boot MyBatis MySQL Thymeleaf 或 Vue理由很实在Spring Boot 把 Tomcat、依赖注入、事务管理都封装好了Transactional一行注解就能控制订单和座位状态的一致性省掉大量配置。MyBatis 的 XML 映射对毕业设计友好SQL 写得清楚答辩时能指着 SQL 讲业务逻辑比 JPA 自动生成更可控。MySQL 免费、资料多事务和行锁机制成熟锁座场景天然适配。前端用 Thymeleaf 服务端渲染最省事想加分就用 Vue 前后端分离但要注意跨域和登录态传递会多花两三天。选型的核心判断标准只有一个你能不能把每一层为什么用它讲明白。讲不明白的技术加了就是负债。2.2 数据库表设计五张核心表与座位状态字段座位图是这个系统的灵魂表设计直接决定后面好不好写。核心表我一般设计成五张表名作用关键字段user用户观众管理员id, username, password, roleshow_info演出场次id, title, hall_id, show_time, priceseat座位静态信息id, hall_id, row_num, col_num, seat_typeseat_status座位动态状态id, show_id, seat_id, status, order_idorder订单id, user_id, show_id, total_price, status这里有个关键设计决策座位静态信息和动态状态必须分表。seat存的是「这个厅第 3 排第 5 列有个座位」是物理事实一个厅一份seat_status存的是「某场演出的这个座位现在卖没卖」每场演出一份。如果合成一张表每加一场演出就要复制一遍座位数据冗余且难维护。seat_status.status用整数表示状态机0可选、1已锁定待支付、2已售出。这个状态机是后面所有逻辑的基础建表 SQL 如下CREATE TABLE seat_status ( id BIGINT PRIMARY KEY AUTO_INCREMENT, show_id BIGINT NOT NULL COMMENT 演出场次ID, seat_id BIGINT NOT NULL COMMENT 座位ID, status TINYINT NOT NULL DEFAULT 0 COMMENT 0可选 1锁定 2已售, order_id BIGINT DEFAULT NULL COMMENT 关联订单, lock_time DATETIME DEFAULT NULL COMMENT 锁定时间用于超时释放, UNIQUE KEY uk_show_seat (show_id, seat_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;uk_show_seat这个唯一索引是防重复售座的第一道防线后面讲并发时会用到。lock_time字段是为「下单后 15 分钟未支付自动释放」准备的没有它用户点了座位不付款这个座位就永久锁死了这是新手最容易漏的字段。2.3 用 SQL 初始化一个剧院厅的座位数据座位数据不用手敲用存储过程或脚本批量生成。假设一个厅 10 排、每排 20 列中间过道留空生成脚本这样写-- 生成座位静态数据hall_id1 DELIMITER $$ CREATE PROCEDURE gen_seats(IN p_hall BIGINT, IN p_rows INT, IN p_cols INT) BEGIN DECLARE r INT DEFAULT 1; DECLARE c INT DEFAULT 1; WHILE r p_rows DO SET c 1; WHILE c p_cols DO -- 第 10、11 列之间是过道跳过 IF c 10 AND c 11 THEN INSERT INTO seat(hall_id, row_num, col_num, seat_type) VALUES(p_hall, r, c, IF(r 3, 2, 1)); -- 前3排为VIP END IF; SET c c 1; END WHILE; SET r r 1; END WHILE; END$$ DELIMITER ; CALL gen_seats(1, 10, 20);逻辑说明外层循环排、内层循环列IF c 10 AND c 11跳过过道位置seat_type用IF判断前 3 排为 VIP值 2其余普通座值 1。参数p_rows、p_cols按实际厅大小改p_hall对应演出厅 ID。跑完这张表就有 180 条座位记录10×20 减去 20 个过道位。这一步做完前端画座位图就有数据源了用row_num和col_num定位每个座位的坐标。3. 选座与锁座的核心实现把并发问题摁死在数据库层3.1 座位状态机与下单流程先把业务流程理清楚代码才不会乱。用户选座的完整链路是进入某场演出的选座页查询seat_status中该show_id下所有座位状态渲染座位图。用户点击座位前端把seat_id发给后端后端尝试把状态从0改为1写入order_id和lock_time。用户确认下单生成订单状态从1改为2。若 15 分钟内未支付定时任务把超时的1改回0清空order_id。这个流程里第 2 步是并发重灾区。两个人同时点同一个座位如果处理不当会双双锁定成功最后卖出两个订单——这就是典型的超卖。3.2 用乐观锁 唯一索引解决并发抢座解决并发锁座我一般用「数据库唯一索引兜底 条件更新判断影响行数」的组合不引入 Redis 也能扛住毕设级别的并发。核心 SQL 是这样UPDATE seat_status SET status 1, order_id #{orderId}, lock_time NOW() WHERE show_id #{showId} AND seat_id #{seatId} AND status 0;对应的 Mapper 方法返回int表示影响行数Update(UPDATE seat_status SET status1, order_id#{orderId}, lock_timeNOW() WHERE show_id#{showId} AND seat_id#{seatId} AND status0) int lockSeat(Param(showId) Long showId, Param(seatId) Long seatId, Param(orderId) Long orderId);Service 层判断返回值Transactional public boolean selectSeat(Long showId, Long seatId, Long orderId) { int rows seatStatusMapper.lockSeat(showId, seatId, orderId); if (rows 0) { // 影响行数为0说明座位已被别人锁定或已售出 throw new BizException(座位已被抢占请重新选择); } return true; }逻辑说明WHERE status 0是乐观锁的精髓——只有当座位当前是「可选」时才更新。数据库对同一行的 UPDATE 会加行锁两个并发请求进来第一个先执行把status改成 1第二个执行时status已经不是 0WHERE不匹配影响行数为 0直接失败。这样不需要额外加锁靠数据库自身的行锁和条件判断就实现了互斥。参数说明showId和seatId联合定位座位orderId用于后续关联订单status0是前置条件。注意Transactional必须加否则更新和后续订单插入不在一个事务里中途失败会留下脏数据。3.3 超时未支付自动释放座位用户锁了座不付款座位不能一直占着。用 Spring 的定时任务扫超时记录Scheduled(fixedRate 60000) // 每分钟执行一次 public void releaseTimeoutSeats() { // 锁定超过15分钟且仍未支付的座位释放回可选状态 int released seatStatusMapper.releaseTimeout( LocalDateTime.now().minusMinutes(15)); log.info(释放超时座位 {} 个, released); }对应 SQLUPDATE seat_status SET status 0, order_id NULL, lock_time NULL WHERE status 1 AND lock_time #{deadline};逻辑说明fixedRate 60000表示每 60 秒跑一次deadline是当前时间减 15 分钟。凡是status1且锁定时间早于这个阈值的说明用户超时未付释放回0。参数 15 分钟按业务定剧院场景一般 10 到 15 分钟合理。这个定时任务要在启动类加EnableScheduling才生效很多人忘了加任务静默不执行排查半天。4. 前后端联调与座位图渲染把数据变成能点的图4.1 后端接口设计查询座位状态前端要画座位图得先拿到某场演出的全部座位及状态。接口设计成一个查询GetMapping(/seats/{showId}) public ResultListSeatVO listSeats(PathVariable Long showId) { // 关联seat和seat_status返回座位坐标状态 ListSeatVO seats seatService.listByShow(showId); return Result.ok(seats); }SeatVO至少包含seatId、rowNum、colNum、seatType、status五个字段。SQL 用seat左连seat_statusSELECT s.id AS seatId, s.row_num, s.col_num, s.seat_type, IFNULL(ss.status, 0) AS status FROM seat s LEFT JOIN seat_status ss ON s.id ss.seat_id AND ss.show_id #{showId} WHERE s.hall_id (SELECT hall_id FROM show_info WHERE id #{showId}) ORDER BY s.row_num, s.col_num;逻辑说明用LEFT JOIN保证即使某座位在seat_status里还没记录新演出首次访问也能返回IFNULL兜底为可选状态。hall_id通过子查询从演出信息里取保证只查这个厅的座位。参数showId是路径变量直接对应演出场次。4.2 前端座位图渲染与点击交互座位图本质是个二维网格用 CSS Grid 或绝对定位都行。核心是把后端返回的列表按rowNum、colNum铺成矩阵// 假设 seats 是后端返回的座位数组 const grid document.getElementById(seatGrid); seats.forEach(seat { const div document.createElement(div); div.className seat statusClass(seat.status); div.dataset.seatId seat.seatId; // 用行列号定位行号做纵坐标列号做横坐标 div.style.gridRow seat.rowNum; div.style.gridColumn seat.colNum; div.onclick () toggleSeat(div, seat); grid.appendChild(div); }); function statusClass(status) { // 0可选 1锁定 2已售 return status 0 ? available : (status 1 ? locked : sold); }逻辑说明gridRow和gridColumn直接映射座位的物理行列过道位置因为数据库里没数据自然留空。statusClass把状态映射成不同 CSS 类可选绿色、锁定黄色、已售灰色。toggleSeat负责选中/取消选中选中时把seatId收集到一个数组下单时一起提交。参数seat.status来自后端前端只做展示真正的状态判断以后端为准防止用户改前端状态骗过系统。4.3 下单接口与座位状态二次校验用户选完座点下单后端不能信任前端传来的座位状态必须再查一次Transactional public Long createOrder(Long userId, Long showId, ListLong seatIds) { // 二次校验确认这些座位当前都是可选状态 int available seatStatusMapper.countAvailable(showId, seatIds); if (available ! seatIds.size()) { throw new BizException(部分座位已被选走请重新选择); } // 逐个锁定座位 for (Long seatId : seatIds) { int rows seatStatusMapper.lockSeat(showId, seatId, null); if (rows 0) { throw new BizException(座位 seatId 锁定失败); } } // 生成订单... }逻辑说明countAvailable先统计这批座位里还有几个是可选的数量对不上说明有人抢先直接抛异常。然后逐个lockSeat任何一个失败就回滚整个事务。参数seatIds是用户选中的座位列表Transactional保证要么全成功要么全回滚不会出现锁了一半的脏状态。这一步是防超卖的最后一道闸别省。5. 避坑与排查那些让毕设翻车的细节5.1 座位状态不同步刷新后全变回可选现象用户锁了座页面刷新后座位又变绿了好像没锁住。原因lockSeat的 UPDATE 没提交事务或者前端查询接口没关联seat_status表只查了seat静态表。解决确认 Service 方法有Transactional确认查询 SQL 用了LEFT JOIN seat_status。用SELECT * FROM seat_status WHERE show_id? AND status1直接查库验证数据到底写没写进去先分清是写的问题还是读的问题。5.2 并发测试时出现同一座位卖出两单现象用 JMeter 或两个浏览器同时抢同一座位两个订单都成功了。原因lockSeat的WHERE条件漏了status0或者用了先查后改的写法先SELECT判断再UPDATE两步之间有时间窗口。解决必须用「条件更新 判断影响行数」的原子写法WHERE status0不能少。另外确认seat_status表有uk_show_seat唯一索引双保险。测试时把线程数调到 50 并发压一下看是否只有一个成功。5.3 定时释放任务不执行现象超时座位一直不释放lock_time早就过了 15 分钟。原因启动类忘了加EnableScheduling或者定时方法所在的类没被 Spring 扫描到没加Component。解决检查启动类注解检查定时任务类是否在SpringBootApplication的扫描路径下。加一行日志在任务开头启动后看控制台有没有打印没有就是没生效。5.4 座位图过道位置显示异常现象座位图中间该空的地方出现了座位或者行列错位。原因生成座位数据时没跳过过道列或者前端gridColumn从 0 开始而数据库列号从 1 开始差一位。解决核对gen_seats里的IF c 10 AND c 11逻辑核对前端定位用的是colNum而不是数组下标。CSS Grid 的行列号从 1 开始和数据库row_num、col_num对齐别混用。5.5 订单金额和座位价格对不上现象VIP 座和普通座价格不同但订单总价按统一价算了。原因下单时只取了演出基础价没按seat_type区分。解决在seat表加price字段或在show_info里存 VIP 价和普通价两个字段下单时按座位类型累加。别在代码里写死价格价格要能从数据库配。6. 进阶技巧把座位图做成可配置的以及怎么验证系统真的可靠带过几届毕设后我发现能拿高分的系统都有一个共同点座位图不是写死的而是可配置的。普通做法是每个厅的座位布局在代码里定死换个厅就得改代码。进阶做法是把厅的布局参数排数、列数、过道位置、VIP 区域存成 JSON 配置生成座位时读配置动态生成。// hall_layout 表存布局JSON如 {rows:10,cols:20,aisles:[10,11],vipRows:3} String layoutJson hallMapper.getLayout(hallId); HallLayout layout JSON.parseObject(layoutJson, HallLayout.class); // 按配置生成座位过道位置跳过 for (int r 1; r layout.getRows(); r) { for (int c 1; c layout.getCols(); c) { if (layout.getAisles().contains(c)) continue; // 插入座位... } }这样管理员在后台改个 JSON 就能新增一个厅不用动代码答辩时这是实打实的加分项。参数aisles是过道列号列表vipRows是 VIP 排数都从配置读灵活。验证系统可靠性我一般做三件事。第一用 JMeter 对锁座接口做 100 并发压测看成功数是否等于座位数多一个就是超卖。第二手动制造超时订单等 15 分钟看定时任务是否释放。第三把数据库里seat_status的状态和前端座位图逐个比对确认状态一致。这三步做完系统基本就稳了。说个我自己的教训早年做这类系统我图省事把座位状态和座位信息合成一张表结果每加一场演出就复制几千条座位数据数据库越跑越慢后来重构分表花了两天。座位静态信息和动态状态一定要分表这个习惯我保持到现在。希望帮到你。本文还有配套的精品资源点击获取 Java大剧院订票选座系统：数据库设计与并发锁座实战
简介本资源为基于Java的大剧院订票选座管理系统毕业设计完整资料包面向计算机相关专业需要完成毕业设计或课程设计的学生以及希望积累B/S架构项目实战经验的开发者。系统采用Java语言与MySQL数据库分为前台与后台前台支持会员注册登录、浏览戏剧戏曲歌舞舞蹈音乐曲艺杂技马戏等节目、在线预订生成订单及个人信息维护后台由管理员审核订单、管理节目分类与用户信息、发布公告推送。压缩包共1619个文件约78.06MB涵盖130个java源码、129个class、96个vue组件、86个html页面、88个css样式、306个js脚本以及sql建库脚本、xml配置、mp4演示视频和说明文档前端资源含svg、gif、png、jpg等图片素材结构完整便于二次开发。目前已有179人学习下载适合需要完整赛题方案、可运行源码、数据库脚本与操作录屏的读者参考帮助快速理解订票选座业务逻辑与前后端交互流程。1. 从一张剧院座位图说起Java 订票选座系统到底在解决什么问题很多人第一次做「基于 Java 的大剧院订票选座管理系统」时脑子里想的是 CRUD用户表、演出表、订单表增删改查一套就完事。真上手才发现最难的从来不是增删改查而是选座——同一排相邻两个座位怎么算、已经被锁的座位怎么实时同步、两个人同时点同一个座位谁赢。这才是这个毕业设计真正的技术含量所在也是答辩老师最爱追问的地方。这个系统面向的场景很具体大剧院有若干演出场次每个场次对应一张座位图观众登录后挑场次、点座位、下单支付后台管理员维护演出和座位状态。它适合正在做 Java 方向毕业设计的同学也适合想练手一个「有并发、有状态、有前后端交互」的完整项目的开发者。数据库设计、座位状态机、并发锁座这三块是决定这个项目能不能拿高分、能不能真正跑起来的关键。下面我按自己带过几届毕设的经验把选型、建库、锁座、避坑一条条讲清楚。2. 技术选型与数据库设计为什么用 Spring Boot MyBatis MySQL2.1 技术栈怎么选才不给自己挖坑毕业设计最忌讳技术栈堆得太花。我见过有人上来就微服务、Redis 集群、消息队列全套结果连座位状态都没跑通答辩时被问「你这个分布式锁解决什么问题」直接卡壳。常见且稳妥的做法是Spring Boot MyBatis MySQL Thymeleaf 或 Vue理由很实在Spring Boot 把 Tomcat、依赖注入、事务管理都封装好了Transactional一行注解就能控制订单和座位状态的一致性省掉大量配置。MyBatis 的 XML 映射对毕业设计友好SQL 写得清楚答辩时能指着 SQL 讲业务逻辑比 JPA 自动生成更可控。MySQL 免费、资料多事务和行锁机制成熟锁座场景天然适配。前端用 Thymeleaf 服务端渲染最省事想加分就用 Vue 前后端分离但要注意跨域和登录态传递会多花两三天。选型的核心判断标准只有一个你能不能把每一层为什么用它讲明白。讲不明白的技术加了就是负债。2.2 数据库表设计五张核心表与座位状态字段座位图是这个系统的灵魂表设计直接决定后面好不好写。核心表我一般设计成五张表名作用关键字段user用户观众管理员id, username, password, roleshow_info演出场次id, title, hall_id, show_time, priceseat座位静态信息id, hall_id, row_num, col_num, seat_typeseat_status座位动态状态id, show_id, seat_id, status, order_idorder订单id, user_id, show_id, total_price, status这里有个关键设计决策座位静态信息和动态状态必须分表。seat存的是「这个厅第 3 排第 5 列有个座位」是物理事实一个厅一份seat_status存的是「某场演出的这个座位现在卖没卖」每场演出一份。如果合成一张表每加一场演出就要复制一遍座位数据冗余且难维护。seat_status.status用整数表示状态机0可选、1已锁定待支付、2已售出。这个状态机是后面所有逻辑的基础建表 SQL 如下CREATE TABLE seat_status ( id BIGINT PRIMARY KEY AUTO_INCREMENT, show_id BIGINT NOT NULL COMMENT 演出场次ID, seat_id BIGINT NOT NULL COMMENT 座位ID, status TINYINT NOT NULL DEFAULT 0 COMMENT 0可选 1锁定 2已售, order_id BIGINT DEFAULT NULL COMMENT 关联订单, lock_time DATETIME DEFAULT NULL COMMENT 锁定时间用于超时释放, UNIQUE KEY uk_show_seat (show_id, seat_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;uk_show_seat这个唯一索引是防重复售座的第一道防线后面讲并发时会用到。lock_time字段是为「下单后 15 分钟未支付自动释放」准备的没有它用户点了座位不付款这个座位就永久锁死了这是新手最容易漏的字段。2.3 用 SQL 初始化一个剧院厅的座位数据座位数据不用手敲用存储过程或脚本批量生成。假设一个厅 10 排、每排 20 列中间过道留空生成脚本这样写-- 生成座位静态数据hall_id1 DELIMITER $$ CREATE PROCEDURE gen_seats(IN p_hall BIGINT, IN p_rows INT, IN p_cols INT) BEGIN DECLARE r INT DEFAULT 1; DECLARE c INT DEFAULT 1; WHILE r p_rows DO SET c 1; WHILE c p_cols DO -- 第 10、11 列之间是过道跳过 IF c 10 AND c 11 THEN INSERT INTO seat(hall_id, row_num, col_num, seat_type) VALUES(p_hall, r, c, IF(r 3, 2, 1)); -- 前3排为VIP END IF; SET c c 1; END WHILE; SET r r 1; END WHILE; END$$ DELIMITER ; CALL gen_seats(1, 10, 20);逻辑说明外层循环排、内层循环列IF c 10 AND c 11跳过过道位置seat_type用IF判断前 3 排为 VIP值 2其余普通座值 1。参数p_rows、p_cols按实际厅大小改p_hall对应演出厅 ID。跑完这张表就有 180 条座位记录10×20 减去 20 个过道位。这一步做完前端画座位图就有数据源了用row_num和col_num定位每个座位的坐标。3. 选座与锁座的核心实现把并发问题摁死在数据库层3.1 座位状态机与下单流程先把业务流程理清楚代码才不会乱。用户选座的完整链路是进入某场演出的选座页查询seat_status中该show_id下所有座位状态渲染座位图。用户点击座位前端把seat_id发给后端后端尝试把状态从0改为1写入order_id和lock_time。用户确认下单生成订单状态从1改为2。若 15 分钟内未支付定时任务把超时的1改回0清空order_id。这个流程里第 2 步是并发重灾区。两个人同时点同一个座位如果处理不当会双双锁定成功最后卖出两个订单——这就是典型的超卖。3.2 用乐观锁 唯一索引解决并发抢座解决并发锁座我一般用「数据库唯一索引兜底 条件更新判断影响行数」的组合不引入 Redis 也能扛住毕设级别的并发。核心 SQL 是这样UPDATE seat_status SET status 1, order_id #{orderId}, lock_time NOW() WHERE show_id #{showId} AND seat_id #{seatId} AND status 0;对应的 Mapper 方法返回int表示影响行数Update(UPDATE seat_status SET status1, order_id#{orderId}, lock_timeNOW() WHERE show_id#{showId} AND seat_id#{seatId} AND status0) int lockSeat(Param(showId) Long showId, Param(seatId) Long seatId, Param(orderId) Long orderId);Service 层判断返回值Transactional public boolean selectSeat(Long showId, Long seatId, Long orderId) { int rows seatStatusMapper.lockSeat(showId, seatId, orderId); if (rows 0) { // 影响行数为0说明座位已被别人锁定或已售出 throw new BizException(座位已被抢占请重新选择); } return true; }逻辑说明WHERE status 0是乐观锁的精髓——只有当座位当前是「可选」时才更新。数据库对同一行的 UPDATE 会加行锁两个并发请求进来第一个先执行把status改成 1第二个执行时status已经不是 0WHERE不匹配影响行数为 0直接失败。这样不需要额外加锁靠数据库自身的行锁和条件判断就实现了互斥。参数说明showId和seatId联合定位座位orderId用于后续关联订单status0是前置条件。注意Transactional必须加否则更新和后续订单插入不在一个事务里中途失败会留下脏数据。3.3 超时未支付自动释放座位用户锁了座不付款座位不能一直占着。用 Spring 的定时任务扫超时记录Scheduled(fixedRate 60000) // 每分钟执行一次 public void releaseTimeoutSeats() { // 锁定超过15分钟且仍未支付的座位释放回可选状态 int released seatStatusMapper.releaseTimeout( LocalDateTime.now().minusMinutes(15)); log.info(释放超时座位 {} 个, released); }对应 SQLUPDATE seat_status SET status 0, order_id NULL, lock_time NULL WHERE status 1 AND lock_time #{deadline};逻辑说明fixedRate 60000表示每 60 秒跑一次deadline是当前时间减 15 分钟。凡是status1且锁定时间早于这个阈值的说明用户超时未付释放回0。参数 15 分钟按业务定剧院场景一般 10 到 15 分钟合理。这个定时任务要在启动类加EnableScheduling才生效很多人忘了加任务静默不执行排查半天。4. 前后端联调与座位图渲染把数据变成能点的图4.1 后端接口设计查询座位状态前端要画座位图得先拿到某场演出的全部座位及状态。接口设计成一个查询GetMapping(/seats/{showId}) public ResultListSeatVO listSeats(PathVariable Long showId) { // 关联seat和seat_status返回座位坐标状态 ListSeatVO seats seatService.listByShow(showId); return Result.ok(seats); }SeatVO至少包含seatId、rowNum、colNum、seatType、status五个字段。SQL 用seat左连seat_statusSELECT s.id AS seatId, s.row_num, s.col_num, s.seat_type, IFNULL(ss.status, 0) AS status FROM seat s LEFT JOIN seat_status ss ON s.id ss.seat_id AND ss.show_id #{showId} WHERE s.hall_id (SELECT hall_id FROM show_info WHERE id #{showId}) ORDER BY s.row_num, s.col_num;逻辑说明用LEFT JOIN保证即使某座位在seat_status里还没记录新演出首次访问也能返回IFNULL兜底为可选状态。hall_id通过子查询从演出信息里取保证只查这个厅的座位。参数showId是路径变量直接对应演出场次。4.2 前端座位图渲染与点击交互座位图本质是个二维网格用 CSS Grid 或绝对定位都行。核心是把后端返回的列表按rowNum、colNum铺成矩阵// 假设 seats 是后端返回的座位数组 const grid document.getElementById(seatGrid); seats.forEach(seat { const div document.createElement(div); div.className seat statusClass(seat.status); div.dataset.seatId seat.seatId; // 用行列号定位行号做纵坐标列号做横坐标 div.style.gridRow seat.rowNum; div.style.gridColumn seat.colNum; div.onclick () toggleSeat(div, seat); grid.appendChild(div); }); function statusClass(status) { // 0可选 1锁定 2已售 return status 0 ? available : (status 1 ? locked : sold); }逻辑说明gridRow和gridColumn直接映射座位的物理行列过道位置因为数据库里没数据自然留空。statusClass把状态映射成不同 CSS 类可选绿色、锁定黄色、已售灰色。toggleSeat负责选中/取消选中选中时把seatId收集到一个数组下单时一起提交。参数seat.status来自后端前端只做展示真正的状态判断以后端为准防止用户改前端状态骗过系统。4.3 下单接口与座位状态二次校验用户选完座点下单后端不能信任前端传来的座位状态必须再查一次Transactional public Long createOrder(Long userId, Long showId, ListLong seatIds) { // 二次校验确认这些座位当前都是可选状态 int available seatStatusMapper.countAvailable(showId, seatIds); if (available ! seatIds.size()) { throw new BizException(部分座位已被选走请重新选择); } // 逐个锁定座位 for (Long seatId : seatIds) { int rows seatStatusMapper.lockSeat(showId, seatId, null); if (rows 0) { throw new BizException(座位 seatId 锁定失败); } } // 生成订单... }逻辑说明countAvailable先统计这批座位里还有几个是可选的数量对不上说明有人抢先直接抛异常。然后逐个lockSeat任何一个失败就回滚整个事务。参数seatIds是用户选中的座位列表Transactional保证要么全成功要么全回滚不会出现锁了一半的脏状态。这一步是防超卖的最后一道闸别省。5. 避坑与排查那些让毕设翻车的细节5.1 座位状态不同步刷新后全变回可选现象用户锁了座页面刷新后座位又变绿了好像没锁住。原因lockSeat的 UPDATE 没提交事务或者前端查询接口没关联seat_status表只查了seat静态表。解决确认 Service 方法有Transactional确认查询 SQL 用了LEFT JOIN seat_status。用SELECT * FROM seat_status WHERE show_id? AND status1直接查库验证数据到底写没写进去先分清是写的问题还是读的问题。5.2 并发测试时出现同一座位卖出两单现象用 JMeter 或两个浏览器同时抢同一座位两个订单都成功了。原因lockSeat的WHERE条件漏了status0或者用了先查后改的写法先SELECT判断再UPDATE两步之间有时间窗口。解决必须用「条件更新 判断影响行数」的原子写法WHERE status0不能少。另外确认seat_status表有uk_show_seat唯一索引双保险。测试时把线程数调到 50 并发压一下看是否只有一个成功。5.3 定时释放任务不执行现象超时座位一直不释放lock_time早就过了 15 分钟。原因启动类忘了加EnableScheduling或者定时方法所在的类没被 Spring 扫描到没加Component。解决检查启动类注解检查定时任务类是否在SpringBootApplication的扫描路径下。加一行日志在任务开头启动后看控制台有没有打印没有就是没生效。5.4 座位图过道位置显示异常现象座位图中间该空的地方出现了座位或者行列错位。原因生成座位数据时没跳过过道列或者前端gridColumn从 0 开始而数据库列号从 1 开始差一位。解决核对gen_seats里的IF c 10 AND c 11逻辑核对前端定位用的是colNum而不是数组下标。CSS Grid 的行列号从 1 开始和数据库row_num、col_num对齐别混用。5.5 订单金额和座位价格对不上现象VIP 座和普通座价格不同但订单总价按统一价算了。原因下单时只取了演出基础价没按seat_type区分。解决在seat表加price字段或在show_info里存 VIP 价和普通价两个字段下单时按座位类型累加。别在代码里写死价格价格要能从数据库配。6. 进阶技巧把座位图做成可配置的以及怎么验证系统真的可靠带过几届毕设后我发现能拿高分的系统都有一个共同点座位图不是写死的而是可配置的。普通做法是每个厅的座位布局在代码里定死换个厅就得改代码。进阶做法是把厅的布局参数排数、列数、过道位置、VIP 区域存成 JSON 配置生成座位时读配置动态生成。// hall_layout 表存布局JSON如 {rows:10,cols:20,aisles:[10,11],vipRows:3} String layoutJson hallMapper.getLayout(hallId); HallLayout layout JSON.parseObject(layoutJson, HallLayout.class); // 按配置生成座位过道位置跳过 for (int r 1; r layout.getRows(); r) { for (int c 1; c layout.getCols(); c) { if (layout.getAisles().contains(c)) continue; // 插入座位... } }这样管理员在后台改个 JSON 就能新增一个厅不用动代码答辩时这是实打实的加分项。参数aisles是过道列号列表vipRows是 VIP 排数都从配置读灵活。验证系统可靠性我一般做三件事。第一用 JMeter 对锁座接口做 100 并发压测看成功数是否等于座位数多一个就是超卖。第二手动制造超时订单等 15 分钟看定时任务是否释放。第三把数据库里seat_status的状态和前端座位图逐个比对确认状态一致。这三步做完系统基本就稳了。说个我自己的教训早年做这类系统我图省事把座位状态和座位信息合成一张表结果每加一场演出就复制几千条座位数据数据库越跑越慢后来重构分表花了两天。座位静态信息和动态状态一定要分表这个习惯我保持到现在。希望帮到你。本文还有配套的精品资源点击获取