简介这份文档资料面向计算机相关专业学生与数据库课程学习者围绕电影院售票管理系统的设计与实现展开可作为《数据库系统概论》等课程的实验参考或课程设计模板。压缩包内共1个doc文件约2.8MB内容为完整的实验文档涵盖需求分析、数据字典、系统结构图、多级数据流图、E-R图与概念模型、逻辑模型、物理模型、存储过程和触发器以及系统实现语言与开发框架的选型说明。文档以大连大学实验报告格式组织包含成员分工、项目目标与功能规定等模块结构清晰便于按章节对照学习。目前已有182人浏览学习适合需要完成数据库课程实验、理解从需求分析到数据库落地全流程的读者参考借鉴。1. 电影院售票管理系统从选座锁座到订单超时的完整落地拆解影院售票和普通电商最大的区别在于座位是稀缺的、不可分割的、且必须实时同步的库存。一张票卖出去同一个座位在任何终端上都不能再被选中。这个约束决定了电影院售票管理系统的技术核心不是增删改查而是并发状态管理。我做过两版影院售票系统第一版用简单的“查询-判断-插入”三步走结果在热门场次开售的前三十秒里同一个座位被卖给了三个人。后来重构时把锁座、订单超时、支付回调这三条链路彻底拆开才把超卖问题按住。这篇笔记按“数据模型怎么定 → 锁座怎么做 → 订单状态机怎么跑 → 前后端怎么配合 → 坑在哪”的顺序展开适合正在做课程设计或准备把影院售票系统真正上线的开发者。2. 影院售票管理系统的数据模型座位、场次、订单三张表怎么拆2.1 影厅座位不是一行一条记录很多人第一反应是给每个座位建一条记录比如 seat 表里存“影厅ID、排号、列号、状态”。这个方案在查询时很方便但问题出在状态字段上同一个座位在不同场次的状态是不同的。3号厅5排6座在上午10点场是可售在下午2点场可能已售。如果把场次维度加进去座位记录数就是“影厅数 × 座位数 × 场次数”一个中型影院一天排50场一个月就是几万条状态记录维护成本很高。我一般会把座位定义和座位状态分开。座位定义表只存物理座位信息状态表按场次动态生成。具体来说-- 影厅座位定义表只存物理座位不存状态 CREATE TABLE hall_seat ( id BIGINT PRIMARY KEY AUTO_INCREMENT, hall_id BIGINT NOT NULL COMMENT 影厅ID, row_no INT NOT NULL COMMENT 排号, col_no INT NOT NULL COMMENT 列号, seat_type TINYINT DEFAULT 0 COMMENT 0普通 1情侣 2无障碍, UNIQUE KEY uk_hall_row_col (hall_id, row_no, col_no) ); -- 场次座位状态表按场次生成只存有状态的座位 CREATE TABLE schedule_seat ( id BIGINT PRIMARY KEY AUTO_INCREMENT, schedule_id BIGINT NOT NULL COMMENT 场次ID, seat_id BIGINT NOT NULL COMMENT 座位ID, status TINYINT DEFAULT 0 COMMENT 0可售 1锁定 2已售, lock_user BIGINT DEFAULT NULL COMMENT 锁定用户, lock_time DATETIME DEFAULT NULL COMMENT 锁定时间, order_id BIGINT DEFAULT NULL COMMENT 关联订单, UNIQUE KEY uk_schedule_seat (schedule_id, seat_id), KEY idx_schedule_status (schedule_id, status) );这样拆的好处是排片时批量插入 schedule_seat 记录默认状态为可售锁座时只更新对应记录查询某场次座位图时直接按 schedule_id 查不需要跨表计算。seat_type 字段用来支持情侣座和无障碍座这类座位在选座界面上要特殊渲染但库存逻辑和普通座位一致。2.2 场次表要冗余已售座位数场次表除了存影片、影厅、开始时间、票价之外我建议冗余一个 sold_count 字段。原因是选座页面需要实时显示“剩余座位数”如果每次都去 schedule_seat 表 count在热门场次高并发下这个 count 查询会成为瓶颈。冗余字段的更新放在订单支付成功之后用乐观锁控制UPDATE schedule SET sold_count sold_count #{count}, version version 1 WHERE id #{scheduleId} AND version #{version} AND sold_count #{count} total_seat;version 字段防止并发更新丢失sold_count count total_seat 这个条件防止超卖。如果更新影响行数为0说明要么版本冲突要么座位不够都需要回滚订单。2.3 订单表的状态字段设计订单表的核心是状态机。我见过有人用“是否支付”“是否取消”两个布尔字段结果出现了“已支付且已取消”的矛盾状态。正确做法是用单一状态字段加时间戳状态值含义可流转到0待支付1已支付、2已取消、3已超时1已支付4已退款2已取消无3已超时无4已退款无订单表还需要存 schedule_id、seat_idsJSON数组或关联表、total_amount、create_time、pay_time、expire_time。expire_time 是下单时间加15分钟超时任务扫描这个字段来关单。3. 锁座与并发控制Redis 分布式锁还是数据库行锁3.1 两种锁座方案的取舍锁座的核心需求是用户点击某个座位后该座位在15分钟内不能被其他人选中。实现方式有两种主流方案。方案一数据库行锁。在事务里用 SELECT ... FOR UPDATE 锁住 schedule_seat 记录然后更新状态为锁定。优点是实现简单不引入额外组件缺点是锁粒度是数据库连接高并发下连接池很快被占满而且如果事务里还有其他耗时操作比如调用支付接口锁持有时间会很长。方案二Redis 分布式锁。用 SETNX 命令对“scheduleId:seatId”加锁设置过期时间15分钟。优点是性能好、不占数据库连接缺点是需要处理锁续期和 Redis 宕机的情况。我一般会混合使用Redis 做第一层拦截数据库做最终一致性保证。具体流程是// 伪代码锁座核心逻辑 public LockResult lockSeat(Long scheduleId, Long seatId, Long userId) { String lockKey seat:lock: scheduleId : seatId; // 第一层Redis SETNX过期时间15分钟 Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, userId.toString(), 15, TimeUnit.MINUTES); if (Boolean.FALSE.equals(locked)) { return LockResult.fail(座位已被锁定); } // 第二层数据库更新带状态条件 int updated scheduleSeatMapper.lockSeat(scheduleId, seatId, userId); if (updated 0) { // 数据库里已经不是可售状态回滚Redis锁 redisTemplate.delete(lockKey); return LockResult.fail(座位已售出); } return LockResult.success(); }对应的 SQL 是UPDATE schedule_seat SET status 1, lock_user #{userId}, lock_time NOW() WHERE schedule_id #{scheduleId} AND seat_id #{seatId} AND status 0;这里 WHERE 条件里的 status 0 是关键它保证了只有可售状态才能被锁定。如果两个请求同时到达数据库的行锁会保证只有一个 UPDATE 成功另一个返回影响行数0。3.2 锁座后的订单创建与超时释放锁座成功后立即创建订单订单状态为待支付expire_time 设为当前时间加15分钟。同时把 schedule_seat 的 order_id 字段更新为订单ID方便后续关联查询。超时释放用定时任务扫描-- 查询已超时的锁定座位 SELECT ss.id, ss.schedule_id, ss.seat_id, o.id AS order_id FROM schedule_seat ss JOIN orders o ON ss.order_id o.id WHERE ss.status 1 AND o.status 0 AND o.expire_time NOW() LIMIT 100;查到之后批量执行更新 schedule_seat 状态回0、清除 lock_user 和 lock_time、更新订单状态为3已超时、删除 Redis 锁。这里要注意加 LIMIT避免一次扫描太多记录导致锁等待。3.3 支付回调的幂等处理支付回调可能重复到达必须做幂等。我的做法是在订单表加一个 pay_trade_no 字段回调时先查这个字段是否已有值UPDATE orders SET status 1, pay_time NOW(), pay_trade_no #{tradeNo} WHERE id #{orderId} AND status 0 AND pay_trade_no IS NULL;如果影响行数为0说明订单已经处理过或者状态不对直接返回成功给支付平台避免重复通知。支付成功后还要把 schedule_seat 状态从1锁定改为2已售并更新场次的 sold_count。4. 前后端配合选座界面与座位状态同步4.1 座位图渲染的数据结构前端选座界面需要知道每个座位的坐标、类型、状态。后端返回的数据结构我一般设计成{ scheduleId: 1001, hallName: 3号厅, rows: 10, cols: 12, seats: [ {id: 1, row: 1, col: 1, type: 0, status: 0}, {id: 2, row: 1, col: 2, type: 0, status: 2}, {id: 3, row: 1, col: 3, type: 1, status: 0} ] }前端根据 row 和 col 计算每个座位的像素位置用 CSS Grid 或绝对定位渲染。status 为0显示可点击1显示灰色锁定2显示红色已售。type 为1的情侣座需要合并两个座位渲染成一个宽座位。4.2 轮询还是 WebSocket座位状态会变化前端需要及时更新。轮询方案是每5秒请求一次座位状态接口实现简单但服务器压力大。WebSocket 方案是建立长连接后端状态变化时主动推送实时性好但需要维护连接。我的经验是如果只是课程设计或小规模使用轮询足够了把间隔设为10秒只请求当前场次的座位状态。如果要上生产环境用 WebSocket 加 Redis 发布订阅当某个座位状态变化时发布消息到对应场次的频道所有订阅了该场次的客户端都能收到更新。4.3 选座冲突的友好提示用户点击一个座位后前端先本地标记为“选中”然后调锁座接口。如果接口返回失败要给出明确提示“该座位刚刚被其他人选中请重新选择”。同时前端要刷新座位图把该座位标记为已售。这里有个细节用户可能一次选多个座位锁座接口要支持批量要么全部成功要么全部失败避免部分锁定导致用户困惑。5. 避坑与排查影院售票系统上线后最容易翻车的五个点5.1 座位超卖现象是同一座位出现多个有效订单现象热门场次开售时同一个座位被多个用户同时下单并支付成功。原因锁座时只用了 Redis 锁但 Redis 锁过期时间到了之后没有续期或者 Redis 主从切换导致锁丢失。数据库层的 UPDATE 没有加 status 0 条件导致重复更新。解决Redis 锁只作为第一层拦截数据库 UPDATE 必须带 status 0 条件并且检查影响行数。支付回调里再次校验座位状态如果发现座位已被其他订单占用自动退款并通知用户。5.2 订单超时未释放现象是座位被锁定但无人支付现象用户下单后没有支付15分钟后座位仍然是锁定状态其他人无法购买。原因定时任务没有跑或者扫描条件写错了。常见错误是只查了 orders 表的 expire_time没有关联 schedule_seat 表导致锁定的座位没有被释放。解决定时任务要同时更新 orders 和 schedule_seat 两张表并且删除 Redis 锁。建议加监控如果待支付订单数量超过阈值就告警。5.3 支付回调丢失现象是用户已付款但订单仍是待支付现象用户支付成功但系统没有收到回调订单状态没有更新座位也没有变成已售。原因支付平台的回调地址配置错误或者回调处理逻辑抛异常导致没有返回成功标识。解决除了被动接收回调还要加主动查询机制。每隔一段时间扫描待支付订单调用支付平台的查询接口确认支付状态。回调处理逻辑要加 try-catch确保任何情况下都返回成功给支付平台避免重复通知。5.4 场次座位图加载慢现象是选座页面打开要好几秒现象用户点击场次后座位图加载超过3秒体验很差。原因schedule_seat 表数据量大查询时没有走索引或者一次性返回了所有场次的座位数据。解决查询只针对当前场次确保 schedule_id 字段有索引。如果座位数很多可以分页或按排加载。前端渲染用虚拟列表只渲染可视区域的座位。5.5 退款后座位没有释放现象是用户退款了但座位仍显示已售现象用户申请退款订单状态变成已退款但座位状态还是已售其他人买不了。原因退款逻辑只更新了订单表没有把 schedule_seat 状态改回可售也没有减少场次的 sold_count。解决退款成功后把对应座位的 status 改回0清除 lock_user、lock_time、order_id同时更新场次的 sold_count 减1。这些操作要放在同一个事务里。6. 用状态机 定时补偿把订单异常率压到千分之一以下订单状态机是影院售票系统里最容易被低估的部分。我第一版系统上线后订单异常率状态不一致、座位与订单不匹配大概在3%左右后来引入状态机加定时补偿压到了千分之一以下。具体做法是所有状态变更必须通过状态机接口不允许直接 UPDATE 数据库。状态机接口里记录每次变更的日志包括变更前状态、变更后状态、操作来源、时间戳。public class OrderStateMachine { private static final MapInteger, SetInteger TRANSITIONS Map.of( 0, Set.of(1, 2, 3), // 待支付 - 已支付/已取消/已超时 1, Set.of(4), // 已支付 - 已退款 2, Set.of(), // 已取消 - 终态 3, Set.of(), // 已超时 - 终态 4, Set.of() // 已退款 - 终态 ); public boolean transition(Long orderId, int fromStatus, int toStatus, String source) { if (!TRANSITIONS.getOrDefault(fromStatus, Set.of()).contains(toStatus)) { throw new IllegalStateException(非法状态流转: fromStatus - toStatus); } int updated orderMapper.updateStatus(orderId, fromStatus, toStatus); if (updated 0) { // 乐观锁失败说明状态已被其他线程修改 return false; } orderLogMapper.insert(orderId, fromStatus, toStatus, source, new Date()); return true; } }定时补偿任务每5分钟跑一次做三件事一是扫描待支付且已过期的订单执行超时关单二是扫描已支付但座位状态不是已售的订单修复座位状态三是扫描已退款但座位状态不是可售的订单释放座位。补偿任务要加分布式锁避免多实例重复执行。验证方法很简单写一个脚本模拟100个用户同时抢10个座位跑完之后检查订单表和座位表的一致性。如果出现座位已售但订单不存在、或者订单已支付但座位可售的情况就说明状态机或补偿逻辑有漏洞。我一般会在测试环境跑三轮每轮1000次并发确认异常率为0才上线。最后说一个习惯每次改完订单相关代码我都会手动构造几种异常场景——支付回调重复到达、支付成功但回调超时、退款时座位已被释放——跑一遍看状态机能不能正确处理。这个习惯帮我省了很多后悔药。希望帮到你。本文还有配套的精品资源点击获取
