SSM订票系统课设实战：事务/锁/幂等性全链路解析

简介：本资源是面向高校软件工程专业本科生的课程设计实战项目，聚焦SSM框架企业级开发实践，完整实现机票与火车票双模预定系统，助力学生掌握从需求分析、分层架构设计到前后端集成的全流程开发能力。压缩包共1651个文件，含51个核心Java业务类（如OrderTicketController、SearchTicketServiceImpl等）、354张PNG界面素材、204个CSS样式文件、91个编译后class字节码、85个XML配置与映射文件，以及JSP视图页、SQL脚本、Jar依赖库等，全面覆盖SSM三大组件（Spring事务管理、SpringMVC请求调度、MyBatis动态SQL与ORM映射）的落地细节，整体大小为50.16MB。已有273人学习下载，资源提供可直接运行的完整工程结构、模块化分层代码、典型业务场景（查询、下单、订单管理、后台管理）的实现逻辑，以及清晰的配置说明与数据库建表脚本，是理解企业级Java Web开发范式与课程设计规范的理想参考样本。

1. 为什么一个“订票系统”课设，我坚持用 SSM 而不是 Spring Boot？

去年带某高校软件工程课程设计时，A同学第一版交上来是 Vue + Express 的前后端分离小 demo，界面清爽、接口跑得飞快——但答辩现场被导师连问三个问题就卡住了：“用户登录态怎么持久化？订单超时未支付如何自动取消？数据库事务在跨表操作（比如扣库存+生成订单）里怎么保证一致性？”他愣住几秒后说：“呃……我用 localStorage 存 token，定时器查订单状态，事务……好像没加。”——这恰恰暴露了多数课设最致命的断层：功能能点出来，但工程落地的关键约束被当成了“高级可选项”。而机票/火车票预定系统，恰恰是检验 SSM（Spring + SpringMVC + MyBatis）这套经典分层架构是否真正吃透的试金石：它不追求炫技，但必须直面并发控制、事务边界、数据一致性、权限隔离、日志追踪这些真实项目里的“硬骨头”。本方案不是教你搭个能点按钮的壳，而是提供一套从需求建模到部署验证全链路闭环的 SSM 实战模板，覆盖软件工程课程设计全部核心评分点：UML 图规范性、MVC 分层合理性、数据库设计范式、事务控制粒度、异常统一处理、前端交互完整性。适合需要交一份“让导师挑不出技术硬伤”的毕设/课设的同学，也适合作为初入 Java Web 开发的工程师建立工程化思维的第一块脚手架。

2. 需求建模与系统边界定义：先画清“谁在什么条件下能做什么”

做课设最怕一上来就写 Controller。我带过的几十份订票类课设里，超过 60% 的返工都源于需求没对齐——比如把“用户可查看余票”简单理解为查一张表，却没意识到“余票”是动态计算值（=总席位 - 已售 - 锁定中），更没考虑“锁定中”状态如何与支付超时联动。本方案的需求建模严格遵循软件工程课程标准，采用 UML 核心图谱驱动开发，所有模块设计均反向追溯至用例图中的参与者与用例。

2.1 核心参与者与用例划分（非功能需求同步嵌入）

我们识别出三类核心参与者：普通用户（注册/登录/查票/下单/支付/退改）、管理员（车次管理/票价设置/订单审核/数据统计）、系统后台（自动锁座/超时释放/库存校验）。注意，“系统后台”不是人，而是需编码实现的定时任务与异步服务，这是很多课设忽略的隐性角色。

关键用例中，必须显式标注非功能约束：

• “查询车次余票”：响应时间 ≤ 800ms（触发缓存策略）
• “提交订单”：强一致性要求，需数据库事务 + 分布式锁（本地锁即可满足课设规模）
• “支付成功回调”：幂等性强制，同一订单号重复回调必须返回相同结果

提示：课程设计答辩时，导师常会问“这个用例为什么需要事务？”——答案不能只说“防止数据错乱”，而要具体到字段级影响。例如：“用户下单时需同时更新train_seat表的 seat_status 字段（锁定为 'L'），并插入order_info表新记录；若仅更新座位状态而订单插入失败，将导致座位被锁死无法释放，造成实际库存损失。”

2.2 数据流图（DFD）Level 0 与 Level 1 关键路径

Level 0 展示系统与外部实体的数据交换：

• 用户 → 系统：登录凭证、车次查询条件、订单支付请求
• 系统 → 用户：登录结果、余票列表、订单确认页、支付二维码
• 管理员 → 系统：车次增删改、票价调整指令
• 系统 → 管理员：运营报表（日订单量、热门线路TOP5）

Level 1 拆解核心处理逻辑，重点标注数据守恒点：

• “余票查询”处理流：接收查询条件 → 查询train_schedule表获取基础信息 → 关联train_seat表统计各席别剩余数 → 应用业务规则（如学生票仅限二等座）→ 返回聚合结果
• “订单创建”处理流：校验用户登录态 → 校验车次存在且未停运 →检查 seat_status='A'（可用）的座位数 ≥ 需求量→ 执行数据库事务：批量更新 seat_status='L' + 插入 order_info + 插入 order_item → 返回订单号与锁定座位号

注意：DFD 中“库存校验”必须是独立处理过程，不可与“更新座位状态”合并。这是为后续扩展预留接口——比如未来接入 Redis 缓存余票，校验逻辑可下沉至缓存层，而主流程不变。

2.3 类图（Class Diagram）核心实体与关系设计

本方案类图严格遵循第三范式，剔除所有冗余字段，关键实体如下：

关系约束必须显式声明：

• TrainSeat.schedule_id → TrainSchedule.schedule_id（外键，ON DELETE CASCADE）
• OrderInfo.user_id → User.user_id（外键，ON UPDATE CASCADE）
• OrderItem.seat_id → TrainSeat.seat_id（外键，ON DELETE RESTRICT —— 已售座位不可删除）

提示：答辩时若被问“为什么 TrainSeat 不直接存 schedule_id + seat_no 作为联合主键？”，回答要点是：“单一主键（seat_id）便于 MyBatis 自动生成主键、简化关联查询SQL；而 seat_no 是业务标识，可能重复（不同车次有相同座位号），不适合作为主键。”

3. 总体架构设计：SSM 三层结构与四个核心模块的职责划分

本方案采用经典 SSM 分层架构，但拒绝教科书式分层——每个包名、每个类职责都对应明确的工程目标。目录结构不是为了好看，而是为了在答辩时能清晰说明“这个类为什么放在这里”。

src/main/java/ ├── com.example.ticket/ │ ├── controller/ // 仅处理HTTP协议层：参数绑定、校验、返回视图或JSON │ │ ├── UserController.java // /user/login, /user/register │ │ ├── TrainController.java // /train/search, /train/detail │ │ └── OrderController.java // /order/create, /order/pay, /order/cancel │ ├── service/ // 业务逻辑中枢：编排DAO、调用工具类、处理事务边界 │ │ ├── UserService.java │ │ ├── TrainService.java // 包含余票计算、车次筛选等核心算法 │ │ └── OrderService.java // **事务入口：@Transactional 注解在此层方法上** │ ├── dao/ // 仅数据访问：MyBatis Mapper 接口 + XML SQL │ │ ├── UserMapper.java │ │ ├── TrainScheduleMapper.java │ │ └── TrainSeatMapper.java // **关键：selectForUpdate 语句在此定义** │ ├── entity/ // POJO：与数据库表一一映射，无业务逻辑 │ │ ├── User.java, TrainSchedule.java, etc. │ ├── dto/ // Data Transfer Object：用于Controller层数据传输，避免暴露entity细节 │ │ ├── TrainQueryDTO.java // 封装查询参数：start, end, date │ │ └── OrderCreateDTO.java // 封装下单参数：scheduleId, seatIds[], userId │ └── util/ // 通用工具：日期格式化、金额计算、ID生成器 │ └── OrderIdGenerator.java // 实现前述 order_id 生成规则

3.1 Controller 层：轻量级协议适配器，拒绝业务入侵

Controller 方法必须满足“单一职责”：只做三件事——接收参数、调用 Service、返回结果。严禁在 Controller 中写 if 判断业务规则、调用 DAO、拼接 SQL。

// TrainController.java @RestController @RequestMapping("/train") public class TrainController { @Autowired private TrainService trainService; /** * 余票查询接口：参数校验由 @Valid 触发，错误统一由全局异常处理器捕获 * 返回值为 List<TrainVO>，VO 是专为前端展示设计的视图对象，不含敏感字段 */ @GetMapping("/search") public Result<List<TrainVO>> searchTrains(@Valid TrainQueryDTO queryDTO) { List<TrainVO> result = trainService.searchTrains(queryDTO); return Result.success(result); } }

设计说明：Result<T>是自定义响应包装类，包含 code、msg、data 字段，强制统一接口规范。@Valid触发 JSR-303 校验（如@NotBlank@Future），校验失败抛出MethodArgumentNotValidException，由GlobalExceptionHandler统一处理返回 400 错误。这样 Controller 干净无分支，答辩时可清晰指出：“所有参数校验在注解层完成，业务逻辑零侵入”。

3.2 Service 层：事务边界与业务编排中心

Service 是 SSM 架构的“心脏”，所有跨 DAO 操作、事务控制、复杂业务规则必须在此层实现。@Transactional 注解必须加在 public 方法上，且该方法由 Spring 容器代理调用（即不能在本类中 self-call）。

// OrderService.java @Service public class OrderService { @Autowired private TrainSeatMapper seatMapper; @Autowired private OrderInfoMapper orderMapper; @Autowired private OrderItemMapper itemMapper; /** * 创建订单：包含完整事务边界 * 1. 校验车次状态 & 座位可用性（SELECT ... FOR UPDATE） * 2. 批量更新座位状态为 'L'（锁定） * 3. 插入订单主表 * 4. 插入订单明细表 * 若任一步骤失败，整个事务回滚 */ @Transactional(rollbackFor = Exception.class) public OrderCreateResult createOrder(OrderCreateDTO dto) throws Exception { // 步骤1：悲观锁查询可用座位（关键！防止超卖） List<TrainSeat> availableSeats = seatMapper.selectAvailableSeatsForUpdate( dto.getScheduleId(), dto.getSeatCount() ); if (availableSeats.size() < dto.getSeatCount()) { throw new BusinessException("余票不足，请重新查询"); } // 步骤2：锁定指定数量座位（更新 seat_status = 'L'） List<Long> seatIds = availableSeats.stream() .limit(dto.getSeatCount()) .map(TrainSeat::getSeatId) .collect(Collectors.toList()); seatMapper.updateSeatStatusLocked(seatIds); // 步骤3&4：创建订单（代码略，调用 orderMapper.insert + itemMapper.insertBatch） // ... return new OrderCreateResult(orderId, seatIds); } }

参数说明：selectAvailableSeatsForUpdate对应 MyBatis XML 中的<select>标签，SQL 使用SELECT ... FROM train_seat WHERE schedule_id = #{scheduleId} AND seat_status = 'A' ORDER BY seat_no LIMIT #{count} FOR UPDATE。FOR UPDATE是 MySQL 悲观锁关键字，确保查询期间其他事务无法修改这些行。这是课设中解决“超卖”问题最直接有效的方式，比 Redis 分布式锁更易理解和实现。

3.3 DAO 层：纯粹的数据搬运工，SQL 与 Java 严格解耦

DAO 层只做一件事：执行 SQL。所有 SQL 语句写在 XML 文件中，禁止在 Java 代码中拼接 SQL（防止 SQL 注入，也符合课程设计规范）。

<!-- TrainSeatMapper.xml --> <mapper namespace="com.example.ticket.dao.TrainSeatMapper"> <!-- 关键：悲观锁查询可用座位 --> <select id="selectAvailableSeatsForUpdate" resultType="TrainSeat"> SELECT seat_id, schedule_id, seat_no, seat_type FROM train_seat WHERE schedule_id = #{scheduleId} AND seat_status = 'A' ORDER BY seat_no LIMIT #{count} FOR UPDATE </select> <!-- 批量更新座位状态为锁定 --> <update id="updateSeatStatusLocked"> UPDATE train_seat SET seat_status = 'L' WHERE seat_id IN <foreach collection="seatIds" item="id" open="(" separator="," close=")"> #{id} </foreach> </update> </mapper>

设计说明：<foreach>标签实现批量更新，避免 N+1 查询。FOR UPDATE必须与@Transactional配合使用——因为 MySQL 的行锁在事务提交后才释放。若 Service 方法未加@Transactional，FOR UPDATE会立即释放锁，失去意义。这是课设中最常见的翻车点之一。

4. 关键模块实现与避坑指南：那些答辩时被追问最多的 5 个问题

4.1 余票动态计算：为什么不能直接查COUNT(*)？

现象：学生常写SELECT COUNT(*) FROM train_seat WHERE schedule_id = ? AND seat_status = 'A'作为余票数。
原因：此 SQL 在高并发下会导致“幻读”——两个用户同时查询，都得到余票=5，然后各自下单买1张，最终库存变为3，但实际应为4。
解决：必须用悲观锁 + 原子更新。先SELECT ... FOR UPDATE锁定一批可用座位，再UPDATE修改状态。锁的粒度是“行级”，而非“表级”，性能可控。课设中 1000 并发内完全够用。

4.2 订单超时自动取消：定时任务 vs 消息队列？

现象：有同学用@Scheduled(fixedDelay = 60000)每分钟扫一遍status=0的订单，但发现延迟高达 5 分钟。
原因：@Scheduled是单线程执行，若上一次扫描耗时 > 60s，下次执行会被阻塞；且无法保证精确到秒级。
解决：采用“时间轮 + 数据库状态机”组合。在OrderInfo表增加expire_time字段（create_time + 15分钟），定时任务只查status=0 AND expire_time <= NOW()的订单，查到后立即UPDATE status=2。课设中每 30 秒执行一次，精度足够。切记：更新时必须加 WHERE 条件AND status=0，防止重复执行。

4.3 支付回调幂等性：为什么order_id不能作为唯一索引？

现象：学生将order_id设为OrderInfo表主键，认为重复回调插入会报主键冲突。
原因：支付平台回调可能因网络重传，导致同一订单多次触发INSERT，但INSERT报错后未处理，导致后续逻辑中断。
解决：支付回调接口必须先SELECT订单状态，若已是已支付则直接返回成功，否则再UPDATE。SQL 如下：

UPDATE order_info SET status = 1, pay_time = NOW() WHERE order_id = #{orderId} AND status = 0;

UPDATE返回影响行数，若为 0 说明已被支付，直接返回 success。这才是真正的幂等。

4.4 MyBatis 一级缓存失效陷阱

现象：在同一个 SqlSession 中，先查seat_id=1001，再更新该座位，之后再查seat_id=1001，结果还是旧值。
原因：MyBatis 一级缓存（SqlSession 级）默认开启，UPDATE操作会清空当前 SqlSession 的缓存，但若SELECT和UPDATE不在同一个 SqlSession（如 Service 方法未加@Transactional），则缓存不会被清空。
解决：所有涉及读写混合的操作，必须包裹在@Transactional中，确保它们共享同一个 SqlSession。课设中只要 Service 方法加了事务，此问题自动消失。

4.5 前端传参安全：为什么seat_id不能直接从前端传入？

现象：前端 HTML 表单直接写<input name="seat_id" value="1001">，后端 Controller 直接接收Long seatId。
原因：恶意用户可篡改seat_id为任意值，绕过余票校验，甚至锁定管理员座位。
解决：所有关键业务参数（如 seat_id, schedule_id）必须通过后端生成的 Token 或 Session 绑定。本方案采用：用户查询车次后，后端将可用座位列表存入HttpSession，下单时只传seatIndex（如 0,1,2），Service 层从 Session 中取出对应seat_id。Session 过期时间设为 15 分钟，与订单超时一致。

提示：答辩时若被问“Session 存大量座位数据会不会内存溢出？”，回答：“课设场景单用户最多查 10 个车次，每个车次最多显示 50 个座位，10×50=500 个 Long，约 4KB，完全可接受。生产环境会用 Redis，但课设无需过度设计。”

5. 全流程验收与答辩技巧：用这 3 张表和 1 个习惯拿下高分

课程设计验收不是看代码能不能跑，而是看工程思维是否闭环。我带过的项目中，能清晰展示以下三张表的同学，基本都能拿到 90+。这三张表不是额外工作，而是你开发过程中自然产生的产物。

5.1 功能点与测试用例对照表（覆盖所有用例图）

提示：这张表必须手填，不能写“已测试”。答辩时导师会随机抽 2 个用例，让你现场演示。建议提前录好 3 个关键用例（UC-03, UC-07, UC-12）的屏幕操作视频，时长控制在 2 分钟内，备用。

5.2 数据库设计评审表（直击范式与约束）

设计依据：train_seat的复合索引(schedule_id, seat_status)能极大加速余票查询（WHERE schedule_id=? AND seat_status='A'）。课设中若没建此索引，SELECT COUNT(*)可能全表扫描，答辩时被问“为什么查询慢”，就只能认栽。

5.3 异常处理与日志追踪表（体现工程素养）

关键动作：在application.properties中配置logging.level.com.example.ticket=DEBUG，并在OrderService.createOrder方法开头加log.debug("创建订单开始: {}", dto);。答辩时打开日志文件，找到一条createOrder的 DEBUG 日志和一条对应的 ERROR/WARN 日志，就能证明你真的写了日志，而不是摆设。

5.4 我的答辩前必做清单（血泪经验总结）

每次答辩前，我都会强制自己走一遍这个流程，少一步都可能被问住：

1. 重启 Tomcat，清空浏览器缓存，用隐身窗口登录
   —— 避免 Session 或 Cookie 缓存导致“我以为能跑，其实不能”的尴尬。曾有同学因浏览器记住旧 token，演示时一切正常，但导师换 Chrome 演示就 401。

2. 打开数据库客户端，执行SELECT * FROM train_seat WHERE schedule_id=1 AND seat_status='L';
   —— 确认锁定逻辑生效。再执行SELECT * FROM order_info WHERE status=0;查看待支付订单。这两条 SQL 是导师最爱现场敲的。

3. 打开logs/tomcat.log，搜索ERROR和WARN
   —— 确保没有未处理的异常堆栈。如果有，立刻定位修复。课设允许有 WARN（如余票不足），但绝不允许 ERROR（如空指针、SQL 语法错误）。

4. 用 Postman 发送一个GET /train/search?start=北京&end=上海&date=2024-05-25请求，复制 Response Body
   —— 准备好 JSON 格式余票数据，导师若问“数据怎么传给前端”，直接粘贴，比口头描述清楚十倍。

5. 把pom.xml中的 Spring 版本、MyBatis 版本、MySQL 驱动版本抄到一张纸上
   —— 导师常问“为什么用 MyBatis 而不用 JPA？”，回答：“课设要求掌握主流 ORM，MyBatis 对 SQL 控制力更强，便于理解事务与锁机制；且pom.xml中 spring-webmvc 5.3.31 与 mybatis-spring 2.0.7 兼容性已验证。”

从那以后我每次带课设，都强制学生在答辩前 24 小时完成这五步，并提交一份《自检报告》（含三张表截图+日志片段+Postman 响应）。不是为了增加负担，而是让每个人在走上讲台前，心里真正有底——你知道哪里可能被问，也知道答案藏在哪行代码、哪张表、哪个日志里。希望帮到你。

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