电影院售票管理系统：锁座、订单超时与并发控制实战

简介：这份文档资料面向计算机相关专业学生与数据库课程学习者，围绕电影院售票管理系统的设计与实现展开，可作为《数据库系统概论》等课程的实验参考或课程设计模板。压缩包内共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 订单表的状态字段设计

订单表的核心是状态机。我见过有人用“是否支付”“是否取消”两个布尔字段，结果出现了“已支付且已取消”的矛盾状态。正确做法是用单一状态字段加时间戳：

订单表还需要存 schedule_id、seat_ids（JSON数组或关联表）、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 Map<Integer, Set<Integer>> 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才上线。

最后说一个习惯：每次改完订单相关代码，我都会手动构造几种异常场景——支付回调重复到达、支付成功但回调超时、退款时座位已被释放——跑一遍看状态机能不能正确处理。这个习惯帮我省了很多后悔药。希望帮到你。

本文还有配套的精品资源，点击获取