Spring Boot电影院购票系统实战：选座并发控制与订单闭环设计

1. 项目整体设计与技术选型1.1 核心需求解析电影院购票系统看上去是个已经被写烂了的选题课程设计里有、毕业设计里有、网上开源项目一抓一大把。但真敢说把这个项目做得能上线、能扛住并发、用户操作体验还顺手的并不多。我当初选这个题目就是看中了它的业务链条足够完整从电影排片、选座、下单、支付到订单管理每一环都切入了真实电商系统的核心痛点麻雀虽小五脏俱全。先梳理一下这个系统必须要面的用户角色和核心功能普通用户注册登录、浏览电影列表、查看电影详情与排片场次、在线选座、提交订单、模拟支付、查看历史订单。管理员管理电影信息、管理影厅与座位、排片管理配置场次、订单查询与统计。这个需求拆出来之后就会发现它本质上是一个“简化版交易系统”覆盖了用户认证、资源展示、状态流转、事务处理、并发控制等后端开发的核心技能点。用Spring Boot来做落地非常合适它生态成熟、起步快社区资料多遇到问题基本都能搜到现成的解决方案。1.2 技术栈选型与取舍技术选型这块我不太建议一上来就堆微服务、消息队列这些重型组件。单机环境能解决的问题不需要提前引入分布式复杂度。我的选型思路是“够用、稳妥、能扩展”最终敲定这套组合技术组件用途选型理由Spring Boot 2.7.x应用框架稳定成熟、资料多、上手快MyBatis-PlusORM省去大量单表CRUD代码分页好用MySQL 8.0主数据库存储用户、电影、排片、订单等核心业务数据Redis缓存 分布式锁缓存热门电影数据、预占座位锁Thymeleaf Bootstrap服务端渲染前端项目体量下不需要前后端分离服务端渲染开发效率高Maven项目管理依赖管理、打包部署方便很关键的一点是前端用Thymeleaf服务端渲染而不是单独拆Vue项目。原因很简单这个项目的重点在后端业务逻辑前端拆出去反而增加了CORS、联调、构建的成本。Thymeleaf能直接复用Controller里的数据模型配合Ajax做局部刷新就足够实现流畅的选座交互了。1.3 数据库设计逻辑数据库是这类系统的地基设计不好后面写代码处处别扭。我按业务模块把核心表拆成了下面几张movie电影信息表包含片名、海报、导演、主演、片长、上映日期、简介、状态。cinema_hall影厅信息表包含影厅名称、座位行数、座位列数。seat影厅座位表记录每个影厅每行每列的座位编号。schedule排片表关联电影和影厅包含播放时间、语言版本、票价。user用户表包含用户名、密码BCrypt加密存储、昵称、手机号。orders订单表关联用户和排片包含订单号、总金额、状态、创建时间。order_seat订单座位关联表记录某订单锁定了哪些座位。这里有一个设计上容易踩坑的点座位和排片的关联。很多人会把座位直接挂在影厅下但真实业务中座位是和“某一场次”绑定的。也就是说同一影厅、不同场次座位是独立的资源。所以我采用了schedule seat order_seat三张表配合通过order_seat表记录某场次下已被哪个订单占用的座位。数据库设计的核心原则就是订单表和座位关联表的粒度要足够细才能支撑后面做并发控制。2. 核心功能模块的实现思路2.1 用户登录与注册的实现用户模块看起来很基础但有一些细节值得认真处理。注册时密码一定要加密存储我选的是Spring Security自带的BCryptPasswordEncoder它每次生成的哈希值都带随机盐比MD5加固定盐要安全得多而且用法很简单Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); }注册时调用passwordEncoder.encode(rawPassword)存入数据库登录时用passwordEncoder.matches(rawPassword, encodedPassword)做比对。这是一个很多初学者容易忽略的点直接把明文密码存库一旦数据库泄露所有用户账号都会暴露这是绝对不可接受的。会话管理我用的是Session方案加拦截器没有引入JWT。原因很简单单体服务端渲染项目Session天然可用配合Spring Boot的拦截器做一个LoginInterceptor在未登录访问需要认证的接口时直接重定向到登录页。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user request.getSession().getAttribute(user); if (user null) { response.sendRedirect(/user/login); return false; } return true; } }再通过WebMvcConfigurer注册拦截器并配置放行路径比引入Spring Security全家桶要轻量得多。管理员角色则在用户表中加一个role字段区分管理员路径单独拦截判断。2.2 电影列表与详情页设计电影列表页的主要逻辑相对直接但缓存策略值得说明。首页和电影列表是用户访问频率最高的入口如果每次请求都去打MySQL数据库压力会比较大。我的做法是把热门电影列表缓存到Redis里设置5分钟的过期时间。public ListMovie listHotMovies() { String cacheKey movie:hot; String json redisTemplate.opsForValue().get(cacheKey); if (StringUtils.isNotBlank(json)) { return JSON.parseArray(json, Movie.class); } ListMovie movies movieMapper.selectList( new LambdaQueryWrapperMovie().eq(Movie::getStatus, 1) ); redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(movies), 5, TimeUnit.MINUTES); return movies; }这里用到了简单的Cache-Aside模式先读缓存、缓存未命中再回源数据库并回填缓存。要注意缓存数据的序列化方式避免Redis里存了不可读的二进制对象导致排查困难。我在项目中统一使用JSON字符串存储配合Fastjson/Jackson直接转换对象简单直观。详情页除了电影基本信息还要展示当前院线的排片场次。排片数据的查询条件通常是电影 日期关联schedule表和cinema_hall表查出每个场次的播放时间、影厅名称、票价、剩余座位数。剩余座位数是通过订单关联表统计出来的这里我用了一条子查询避免N1问题SELECT s.*, h.name AS hall_name, h.row_count, h.column_count, (SELECT COUNT(*) FROM order_seat os WHERE os.schedule_id s.id) AS sold_count FROM schedule s LEFT JOIN cinema_hall h ON s.hall_id h.id WHERE s.movie_id #{movieId} AND s.play_date #{date} ORDER BY s.play_time2.3 选座与下单的业务流程选座是整个系统的核心链路业务流程是用户选电影 - 选场次 - 进入座位图 - 选择座位 - 提交订单 - 锁定座位 - 模拟支付 - 生成订单。这个流程每一步都涉及状态检查尤其是座位图的渲染和订单提交之间的并发一致性是整个项目的难点。座位图渲染逻辑前端根据影厅的行列数动态生成座位格子已经售出或被锁定的座位显示为灰色不可选可选座位高亮显示。座位状态的后端判定规则是已售出该排片下存在支付成功的订单且订单关联了该座位。锁定中该座位存在订单但订单未支付且未超过锁定时间。用户点击座位后前端把选中的座位ID列表和排片ID传递到后端后端做校验后创建订单并锁定座位。这个环节就是最典型的并发安全场景。我记得第一次测试时同时开两个浏览器窗口抢同一个座位结果两个订单都创建成功了。这就是典型的超卖问题我在后面专门花了一个章节来解决选座并发控制这是整个项目最有含金量的地方。3. 选座并发控制方案3.1 先看清并发问题的根源一个场次有一批座位用户A和用户B同时看中了第5排第6座两个请求几乎同时到达后端。传统做法是先查询座位是否空闲如果空闲则创建订单并占用座位。但“查询-判断-写入”这三步之间存在时间差就会出现两个请求都通过了“空闲判断”都写入了订单于是同一个座位被卖出了两次。这个问题的本质是竞态条件race condition只有在并发场景下才会暴露。解决思路无非两种一是让座位资源从查询到占用保持原子性别人在我操作期间碰不到它二是在数据库层面加约束让第二个写入请求直接失败。我会从最简单的方案说起逐步过渡到最终版本。3.2 方案一数据库行级锁利用MySQL的SELECT ... FOR UPDATE给座位记录加排他锁事务提交后锁才释放。这样当一个请求在事务中锁定座位时另一个请求查询同一批座位就会被阻塞直到第一个事务结束。Transactional public Order createOrderWithLock(Long scheduleId, ListLong seatIds) { ListSeat seats seatMapper.selectForUpdate(scheduleId, seatIds); // 检查seats中是否有已售出或已锁定的座位 // 如果没有插入订单和关联记录 }对应的Mapper方法select idselectForUpdate resultTypecom.example.entity.Seat SELECT s.* FROM seat s INNER JOIN order_seat os ON os.seat_id s.id WHERE os.schedule_id #{scheduleId} AND s.id IN foreach collectionseatIds itemseatId open( separator, close) #{seatId} /foreach FOR UPDATE /select这个方案能解决问题但有几个缺陷一是如果座位没有对应的order_seat记录就锁不到任何行所以必须先保证每张座位在order_seat里预留记录二是锁的范围可能扩大影响同一场次其他座位的并发下单三是在高并发下数据库连接容易被长时间占用。3.3 方案二Redis预占锁实现这是我在项目中最终采用的方案。思路是在Redis中使用SETNX命令对每个座位ID创建一个短时锁锁的value是用户ID过期时间设置为10分钟。谁成功创建了这个key谁就获得了座位的预占权。public boolean tryLockSeat(String keyPrefix, Long seatId, Long userId) { String lockKey seat:lock: keyPrefix : seatId; Boolean result redisTemplate.opsForValue() .setIfAbsent(lockKey, String.valueOf(userId), 10, TimeUnit.MINUTES); return Boolean.TRUE.equals(result); }下单流程改造后变成前端提交排片ID和座位ID列表。后端遍历座位ID逐个尝试获取Redis锁。如果某个座位锁获取失败说明该座位已被别人预占直接返回“座位已被锁定”。全部锁获取成功后进入数据库事务创建订单并写入座位关联记录。事务成功后删除Redis锁事务失败或订单超时未支付则删除锁。这个方案的好处是锁的粒度精确到单个座位互不干扰而且Redis的操作性能远高于数据库行锁。用户90秒内不支付订单自动取消同时释放Redis锁座位重新变成可选状态。3.4 规避删锁的经典坑Redis锁的使用中有个非常经典的坑用户A通过Redis锁抢到了座位但订单还没创建完锁的过期时间到了锁自动释放。此时用户B抢到了座位锁开始创建订单。紧接着用户A的事务完成了代码里执行delete lockKey把用户B的锁删掉了。这时用户C又来抢座位也能成功导致A、B、C三个人都以为自己买到了座位。正确的删除方式是在删除前校验锁的value是否还是自己的用户ID确认是自己的锁才删除用Lua脚本保证原子性public void releaseLock(String lockKey, Long userId) { String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; redisTemplate.execute(new DefaultRedisScript(script, Long.class), Collections.singletonList(lockKey), String.valueOf(userId)); }另外还要把过期时间设置成合理的业务时间我最初设置的是5分钟后来发现在支付环节停留时间稍长就会导致锁过期失效改成了10分钟同时配合订单的自动取消任务兜底。3.5 定时清理超时订单锁有自动过期订单也不能无限期占用座位。我在项目中用Spring的Scheduled注解实现了一个定时任务每30秒扫描一次订单表将创建时间超过10分钟且状态为“待支付”的订单改为“已取消”并释放该订单关联的座位锁。Scheduled(fixedRate 30000) public void cancelExpiredOrders() { LocalDateTime deadline LocalDateTime.now().minusMinutes(10); ListOrder expiredOrders orderMapper.selectExpiredPendingOrders(deadline); for (Order order : expiredOrders) { order.setStatus(OrderStatus.CANCELLED.getCode()); orderMapper.updateById(order); ListOrderSeat orderSeats orderSeatMapper.selectList( new LambdaQueryWrapperOrderSeat().eq(OrderSeat::getOrderId, order.getId()) ); for (OrderSeat os : orderSeats) { releaseLock(seat:lock: os.getScheduleId() : os.getSeatId(), order.getUserId()); } } }这里需要注意的是定时任务要和消费者的支付确认做联动处理。如果一个订单在超时边缘被支付了定时任务需要先判断订单状态是否为待支付只有在确认仍是待支付时才执行取消避免扣了用户的款还取消了订单这种严重问题。4. 前端页面与接口交互4.1 页面结构化拆分前端我用Thymeleaf模板引擎配合Bootstrap来实现整体页面分成三大块公共布局导航栏、用户登录状态、底部版权信息。用户端页面首页、电影详情、选座页面、订单确认页、订单列表页。管理端页面电影管理、排片管理、影厅管理、订单管理。Thymeleaf的布局用th:fragment语法抽公共部分比如导航栏单独抽出一个fragment各个页面通过th:replace引入避免重复写HTML。这个用法比JSP的include更优雅而且天然支持服务端数据渲染。选座页面是交互最复杂的部分座位图用CSS Grid布局根据影厅的行列数动态生成。每行每列用一个div表示包含座位ID和状态信息默认状态从后端的接口获取。4.2 用Ajax做座位状态刷新选座页面的前端逻辑有几个关键点进入页面后向后端发起请求获取当前排片的座位状态。已被售出或锁定的座位置灰不可点击。用户点击座位座位高亮为选中状态再次点击取消选中。右上角显示当前已选座位数量和总价。点击提交按钮后把所有选中座位ID一次性提交到后端。这些交互全部用原生JavaScript加jQuery的Ajax实现不额外引入前端框架。代码不复杂但要注意防重复提交用户点击“提交订单”后按钮要立即置为禁用状态防止用户手误连点导致创建多个订单。4.3 订单确认与支付模拟订单确认页展示用户选择的场次、座位明细、总价以及一个“模拟支付”按钮。很多新手在这个环节容易犯的错误是订单创建成功后直接跳出支付按钮但订单状态的管理其实是两个步骤提交订单生成订单锁定座位状态为pending待支付。模拟支付将订单状态从pending改为paid已支付正式完成座位占用。这样设计的理由是订单创建和支付在真实场景中是两个独立的动作支付环节可能因为各种原因失败或超时。如果创建订单时直接置为已支付就无法实现超时取消、座位自动释放机制。模拟支付的接口也很简单前端把orderId传给后端后端校验订单属于当前登录用户且状态为待支付然后更新状态并标注支付时间。为了演示效果我在支付接口中故意加了500毫秒的Thread.sleep模拟支付网关的处理延迟。4.4 后台管理页的表格联动管理端页面基本是标准CRUD但有一个联动场景值得提一下排片管理页面。新增排片时要选择电影、选择影厅、设置播放时间和票价。这里有个业务校验很容易被忽略同一个影厅在同一时间段只能排一场电影播放时间需要和片长做重叠校验。public boolean checkScheduleConflict(LocalDateTime playTime, Integer hallId, Integer movieDuration) { LocalDateTime endTime playTime.plusMinutes(movieDuration 20); // 加20分钟散场时间 ListSchedule schedules scheduleMapper.selectList( new LambdaQueryWrapperSchedule() .eq(Schedule::getHallId, hallId) .eq(Schedule::getPlayDate, playTime.toLocalDate()) ); for (Schedule s : schedules) { LocalDateTime sEnd s.getPlayTime().plusMinutes(s.getMovieDuration() 20); if (playTime.isBefore(sEnd) endTime.isAfter(s.getPlayTime())) { return false; } } return true; }这个场景我一开始没做校验导致测试数据里出现了同一影厅同时上映两部电影的笑话。数据校验无小事越细节的地方越能体现一个开发者的工程素养。5. 常见问题与排查心得5.1 事务不生效的问题在开发期间我遇到过Transactional明明加了却不起作用的情况。订单状态更新一半后面抛异常前面的数据库操作也没有回滚导致座位被占用但订单数据不完整。排查后发现是两个原因一是方法被同类内部调用Spring事务是基于AOP代理的内部调用不走代理对象事务注解自然失效。二是异常被方法内部catch住了事务感知不到异常自然不会回滚。解决办法很简单把需要事务的方法拆分到独立的Service类中确保通过Spring容器调用异常要么抛出要么在catch里手动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()标记回滚。5.2 数据库时间字段的时区坑电影院购票系统对时间非常敏感排期、订单时间、定时任务都依赖准确的时间。我排查过一个很有意思的问题订单显示创建时间比实际时间晚了8个小时。原因是MySQL JDBC连接的serverTimezone参数设置不当默认使用了UTC时区而本地是东八区。解决办法是在数据库连接URL中显式指定serverTimezoneAsia/Shanghai并在Java侧统一使用LocalDateTime不依赖系统默认时区。另外排片表里存的是“播放日期”和“播放时间”两个字段日期用LocalDate、时间用LocalTime不要全部塞进一个DateTime字段后续按日期查询排片时会遇到很多不必要的转换问题。5.3 Redis缓存穿透与失效场景我有一个热点数据缓存策略是缓存电影列表5分钟这就引出了缓存穿透问题如果用户频繁刷新一个不存在的电影ID的详情页请求会绕过缓存直接打到数据库。我当时没太在意这个问题后来测试时发现数据库日志多了很多可疑的查询。解决方式有两种一是对不存在的电影ID也在Redis里缓存一个空值占位设置较短的过期时间二是用布隆过滤器在请求到达缓存前过滤掉大部分非法ID。考虑到项目体量我采用了第一种简单方案够用且容易理解。比较隐蔽的是缓存失效的雪崩问题如果所有电影信息的缓存都设置了相同的过期时间同一时刻集体失效数据库瞬间压力就上来了。我的做法是给过期时间加一个随机偏移量让缓存的失效时间散布在不同的时间点从根源上避免了这个问题。5.4 部署时端口被占用最后说说一个看似低级却很影响心情的问题本地启动Spring Boot项目时提示端口被占用。这个问题大多数情况下是上一个开发实例没有完全关闭监听8080端口的进程还活着。Windows下用netstat -ano | findstr 8080找到PID再用taskkill /PID 进程号 /F强制结束。为了避免反复出现我在项目中配置了server.port8080同时设置了spring.devtools.restart.enabledtrue开发时改动代码自动重启能少踩很多手工重启带来的操作失误。6. 项目扩展方向与我的个人体会做完这个项目之后我最大的感受是选座购票系统虽然业务不算复杂但把并发控制、缓存策略、事务管理、定时任务这些后端核心技能全部串了起来形成了一个完整的实战闭环。如果你的目标是找工作或者巩固Spring Boot技能这个项目是非常合适的练手选题。如果想让这个项目更有亮点可以从几个方向继续扩展引入消息队列将订单创建和支付回调解耦提升系统吞吐量。将Redis锁替换成Redisson的看门狗机制进一步优化锁的自动续期问题。接入真实支付网关SDK替代模拟支付让业务流程更贴近生产环境。增加观影评价、积分体系、会员折扣等附加功能丰富业务层次。我个人在实际操作中最受益的环节是并发锁的方案演进从一开始的数据库FOR UPDATE到Redis SETNX锁再到解决锁误删的Lua脚本每一步都是被真实问题推着走这种“遇到问题 - 分析根因 - 设计方案 - 落地验证”的循环才是做项目最大的收获。如果你也在做类似的单体应用项目我强烈建议不要只停留在“增删改查能跑通”的层面多想一想数据一致性、异常场景、用户体验这些边角问题你会发现自己对系统的理解会完全不一样。