B/S架构电影院售票系统实战：并发控制与订单状态机解析

1. 项目概述与选题思路

1.1 为什么B/S架构成了电影院售票系统的首选

先说结论：B/S架构（Browser/Server，浏览器/服务器架构）做影院售票系统，是计算机毕业设计里"性价比"最高的选择之一。原因有三层。

第一层是技术层面。现在的影院售票系统，用户端本质上就是"打开网页看排片、选座位、下单支付"，管理员端就是"维护影片信息、排场次、管订单"。这两类操作天然适合浏览器完成——用户不需要安装任何客户端，浏览器打开即用，服务器端统一部署，所有逻辑集中在后端。相比C/S架构（Client/Server，客户端/服务器架构）需要给每个用户装客户端、升级还要重新分发安装包，B/S架构的维护成本低了一个量级。

第二层是毕设层面。毕业设计最怕的不是功能做不出来，而是"做完了不知道怎么讲清楚"。B/S架构的三层结构（表现层、业务逻辑层、数据访问层）在答辩时特别好讲：每一层职责清晰，数据流向明确，配合核心代码能讲得头头是道。而且B/S架构的参考资料极多，遇到问题容易排查，能显著降低翻车概率。

第三层是实用层面。我见过不少同学一上来就想搞微服务、搞高并发、搞分布式，结果毕设把自己坑进去，光环境搭建就花了两周。影院售票系统这个选题，业务场景真实但不复杂：影片管理、排片管理、座位选择、订单生成、支付模拟、数据统计。该有的业务逻辑都有，能体现出完整的系统设计能力，又不会因为过度设计导致无法按期完成。这才是毕设选题的正确姿势——用合理的技术解决合理的问题，而不是用复杂的技术解决不存在的问题。

1.2 一个合格的影院售票系统到底要做什么

很多同学拿到"影院售票系统"这个题目，第一反应是"不就是卖票吗"，然后就开始写代码了。结果做着做着发现：用户的登录注册要做吧？影片列表要展示吧？选座位怎么处理？订单过期了怎么办？管理员怎么排片？票房数据怎么统计？——需求边界一旦模糊，开发就会陷入"改了又改"的泥潭。

所以在动手写任何代码之前，我强烈建议先把系统边界画清楚。一个标准的影院售票系统，核心用户角色就两类：

• 普通用户（前台）：注册登录、浏览影片列表、查看影片详情、选择场次、在线选座、提交订单（模拟支付）、查看历史订单、个人信息管理。
• 系统管理员（后台）：影片信息管理（增删改查）、影厅信息维护、排片管理（为影片分配影厅和时间段）、订单管理（查看所有订单、处理退票）、票房统计与数据看板。

画清楚边界之后，你会发现这个系统的核心难点其实只有两个：座位的唯一性约束和订单的状态流转。掌握了这两个核心逻辑，整个系统就成立了。后面的章节我会详细拆解这两块。

2. 系统架构与技术栈选型

2.1 后端技术栈：Servlet + JSP还是Spring Boot？

这是B/S架构毕设里最经典的分岔路口。我分开说，你们按自己的情况选。

传统路线：Servlet + JSP + MySQL。这是很多学校教材里的标准组合。JSP直接在页面上写Java代码，Servlet处理请求逻辑，JDBC操作数据库。优点是完全贴合教学路线，答辩时每一步都能跟课程对应上，适合Java基础偏弱、想稳扎稳打完成的同学。缺点也明显：JSP里嵌Java代码，前后端耦合严重，页面改个样式都可能动到Java逻辑，代码维护比较痛苦。

主流路线：Spring Boot + Thymeleaf（或Freemarker）+ MyBatis/JPA。Spring Boot这两年几乎成了Java Web开发的默认起点，内嵌Tomcat，打一个Jar包就能跑，配置比SSH时代简化了太多。MyBatis做持久层，SQL自己控制，便于在答辩时讲清楚每一条查询的逻辑。Thymeleaf作为服务端模板引擎，跟JSP类似，但语法更干净，跟HTML标签融合得好。

我个人推荐Spring Boot这条线。原因不是"追新"，而是Spring Boot把很多繁琐的配置变成了"约定优于配置"，省下来的精力可以花在业务逻辑上。举个例子：JSP时代配置一个视图解析器要写好几行XML，Spring Boot里加一个依赖、在application.properties里写一行前缀后缀就完了。你省下的时间，用来做选座逻辑和订单状态机，不香吗？

2.2 前端方案：服务端渲染还是前后端分离？

毕设阶段我不建议上前后端分离（Vue + RESTful API）。不是说这个方向不好，而是对毕设来说成本偏高。前后端分离意味着你需要同时维护两套工程、处理跨域问题、设计API文档、联调接口，一旦时间紧张，很容易两头都做不好。

更务实的做法是服务端渲染：后端用Thymeleaf或JSP渲染页面，数据从后端Model传到页面模板，整体是一个完整的多页面应用（MPA）。用户访问 /movie/list 就拿到完整的影片列表页，点击某部电影跳到详情页，请求参数挂在URL上或者通过表单提交。这种模式的好处是：数据流转链路短，出了问题容易定位；而且答辩演示时，浏览器地址栏的变化直接对应后台URL映射，逻辑一目了然。

当然，为了体现"交互性"，选座页可以适当引入一些Vue或原生JavaScript来提升体验——比如点击座位选中、已售座位禁选、票价自动计算。局部动态交互 + 整体服务端渲染，是毕设阶段最优雅的折中方案。

2.3 数据库设计：五张核心表的拆解

数据库设计的好坏，直接决定了开发后期是"一路顺风"还是"处处补丁"。影院售票系统最核心的表就五张，我按建模顺序拆给你看。

第一张：用户表（user）。字段包括用户ID（主键，建议自增）、用户名、密码（必须加密存储）、手机号、注册时间、状态（正常/禁用）。这里要注意：密码存储绝不能用明文，至少要用MD5加盐或者BCrypt。答辩时老师问"怎么保证用户安全"，你能说出"密码加盐哈希，盐值随机存储"，就已经超过一大半同学了。

第二张：影片表（movie）。字段包括影片ID、片名、导演、主演、海报URL、影片简介、类型（动作/科幻/爱情...）、时长、上映时间、状态（热映/即将上映/已下架）。海报URL建议存服务器相对路径，不要把整条URL写死——因为换服务器或换域名时，全表更新URL会让人崩溃。

第三张：影厅表（hall）。字段包括影厅ID、名称（1号厅/2号厅...）、座位行数、座位列数。影厅表拍板了座位的"网格大小"。比如一个影厅10行×12列，那就是120个座位。这里有个小技巧：影厅表里直接存row_count和col_count，后面生成座位图的时候循环两层就能搞定，不需要单独建一张座位表。

第四张：排片表（schedule）。字段包括排片ID、影片ID（外键）、影厅ID（外键）、放映时间、结束时间（可自动算出，也可存储）、票价。排片表是连接影片和影厅的桥梁，也是用户购票时直接面对的核心数据。注意一个影厅在同一时间段只能有一场放映，这是排片功能的唯一性约束。

第五张：订单表（orders）。字段包括订单ID、订单编号（业务上唯一，建议用时间戳+随机数生成）、用户ID（外键）、排片ID（外键）、座位信息（如"3排5座,3排6座"）、总价、状态（待支付/已支付/已取消/已退票）、创建时间、支付时间。订单表是系统里最核心的表，也是后面并发控制的主战场。

另外需要一张座位状态表或座位占位表（order_seat），记录每个排片ID下哪些座位已被锁定或售出。为什么不能只靠订单表？因为"已下单未支付"时座位也需要被锁定。这就是后文要展开的并发控制逻辑。

3. 核心功能模块设计与实现

3.1 用户端：从选片到下单的完整链路

用户端的核心流程可以串成一条线：注册登录 → 浏览影片 → 查看详情 → 选择场次 → 选座 → 提交订单 → 模拟支付 → 查看订单。

这里面最需要花心思的是"选座"环节。第一步，用户点击某场次后，后端要根据排片ID（schedule_id）查出该影厅的行列信息，同时查出所有已被占用的座位（已售出或锁定中），生成一张座位图传入页面。第二步，前端渲染出二维网格座位图，可用座位显示为可点击状态，已占用座位置灰，用户最多可连续选座（一般限制单笔订单不超过6张）。第三步，用户选完座位提交时，前端把所选座位列表（格式如"A1,B1"）和排片ID传给后端，后端要在同一事务里完成"检查座位是否仍可用 → 创建订单 → 锁定座位"三步操作。

这里有个业务细节容易忽略：座位锁定不等于售出。用户提交订单后通常有15～30分钟的支付时间窗口，在这个窗口内座位必须对其他人保持"不可用"状态，否则就会出现"两个人买到同一个座位"的严重事故。等到用户支付成功，座位才真正变为"已售出"；如果超时未支付，座位要重新释放。

3.2 管理员端：排片背后的时间冲突校验

排片功能看起来简单——"选个电影，选个影厅，选个时间段，保存"，但做起来有个隐蔽的坑：同一个影厅不能在同一时段放映两部电影。

比如1号厅在18:00到20:00放映A电影，管理员又想把B电影排到1号厅的19:00到21:00，这就必须拦截。实现方式是在新增排片时做一个区间重叠判断：

newStart < existingEnd && newEnd > existingStart

只要这个条件成立，说明时间段存在冲突，后端直接拒绝保存并提示管理员。判断逻辑不复杂，但漏掉这一步的系统，在实际使用中必然出现排片冲突事故。除了时间冲突，还需要注意影厅容量校验：一场电影的座位数就等于影厅的行×列，不用单独配置，从影厅表查询即可。

管理员端的另一个重点是订单管理。订单列表需要支持按场次、按影片、按状态筛选，复杂的订单状态（待支付/已支付/已取消/已退票）决定了管理员能看到哪些操作按钮（例如已支付订单才允许做退票）。这些逻辑不涉及高深技术，但要做到状态与操作匹配，逻辑闭环才是关键。

3.3 订单状态机：如何把"状态"管明白

很多同学做订单功能时，喜欢在Service层写一堆if-else判断状态，改了又改，最后自己都乱。我建议用一个简单的状态流转图来理清逻辑：

• 状态定义：待支付（0）、已支付（1）、已取消（2）、已退票（3）。
• 流转规则：待支付 → 用户取消 → 已取消；待支付 → 支付成功 → 已支付；已支付 → 管理员退票 → 已退票；待支付 → 超时未支付 → 系统自动置为已取消。

在代码层面，每次操作订单状态时都要带上前置状态判断。比如支付操作，前置状态必须是"待支付"；退票操作，前置状态必须是"已支付"。这就是经典的状态机模式。对应的数据库操作里，用带条件更新的SQL可以把并发风险降到最低：

UPDATE orders SET status = 1, pay_time = NOW() WHERE order_id = ? AND status = 0

这条SQL的巧妙之处在于：只有当订单当前状态确实是0（待支付）时，更新才会成功。如果执行后受影响行数为0，说明订单状态已变化（比如已被取消或已被支付），本次操作直接驳回。这是防并发的一层安全兜底。

4. 关键环节实操详解

4.1 座位并发控制的三种方案对比

影院售票系统的"技术含金量"很大程度体现在选座的并发控制上。想象一个场景：两个用户同时打开同一场次的座位图，都看中了3排5号座，同时点了提交。如果没有并发控制，就可能两个人都下单成功——这是绝对不能被接受的事故。下面按从简单到高级排序，给你三套方案。

方案一：HTTP请求级悲观锁（限制条件）。在"锁定座位"时，启动一个数据库事务，在执行检查/更新语句时，用SELECT ... FOR UPDATE把涉及的行锁住。其他事务要想操作同一行，必须等当前事务提交或回滚。实现直接，适合数据量不大的系统。

方案二：SQL条件更新（乐观锁）。核心写法类似上文的订单状态更新：

UPDATE order_seat SET status = 1 WHERE schedule_id = ? AND seat_row = ? AND seat_col = ? AND status = 0

如果受影响行数等于1，说明这个座位从"可用"状态成功变成"锁定"状态，抢占成功；如果等于0，说明座位已经被别人抢走，直接返回"座位已售出"。不需要显式加锁，数据库的行级原子性帮我们兜底，实现成本低、性能好。毕设场景强烈推荐这个方案。

方案三：Redis分布式锁（超出毕设范围）。引入Redis做分布式锁位、记录座位状态，适合分布式部署、高并发的生产级系统。毕设来说有点过度设计，但答辩被问到"如果系统部署在多台服务器怎么办"时，可以作为扩展思路提一提。

我个人在项目中采用方案二为主、方案一的批量操作为辅。锁定时，前端传入多个座位（比如3排5座+3排6座），后端在事务里先用SELECT ... FOR UPDATE锁定排片记录，然后循环执行每行的条件更新。事务保证要么全部座位锁定成功，要么全部回滚释放，不会出现只锁了一半座位的脏数据。

4.2 订单超时未支付，座位怎么自动释放

用户下了单但迟迟不支付，这堆"僵尸订单"如果一直占着座位，对影院来说就是白白损失。因此需要一套定时释放机制。

实现方案很简单：在服务器启动时通过定时任务框架（如Spring的@Scheduled）配置一个定时器，每隔一分钟扫描一次订单表，把所有"创建时间超过15分钟且状态仍为待支付"的订单找出来，执行两步操作：把订单状态改为"已取消"，同时释放该订单占用的座位（把order_seat里对应记录状态改回0或直接删除）。两步操作要放在同一个事务里，避免出现在释放座位的瞬间，订单状态还没更新的不一致窗口。

关于超时时间，建议做成可配置项，不要写死在代码里。可以在配置文件中加一个参数order.expire.minutes=15。为什么？因为答辩演示时，你肯定不想让评委等15分钟看效果，可以把配置改成1分钟甚至30秒，演示超时释放功能时立竿见影。

定时扫描的频率也不宜过高。每分钟扫一次足够，频率太高纯属消耗数据库资源。这里要跟评委解释清楚一个概念：轮询是幂等的，即使某一轮扫描中途宕机，下一轮扫描会把遗留的过期订单一并处理掉，所以每分钟扫一次并不存在安全隐患。

4.3 前端选座交互：从矩阵渲染到动态计算

选座页的前端是整个系统里交互最复杂的部分，我当初花了一天时间打磨。核心逻辑分成三块：

第一块：座位图渲染。后端把影厅的行列数、已被占用的座位集合传给前端。前端用两层循环动态生成座位网格。每个座位用div实现，带上自定义属性>