一朵小Rose1. 项目背景与核心需求
假期列车售票系统作为典型的交通票务管理应用，在高校计算机相关专业的毕业设计中具有极高的选题率。这个选题的价值在于它完整覆盖了企业级应用开发的三大核心要素：高并发事务处理（票务库存）、复杂业务规则（座位分配、票价计算）和多端协同（后台管理+用户购票）。
我选择SpringBoot+Vue的技术栈主要基于以下考量：
- SpringBoot的自动配置特性能够快速搭建RESTful API服务，其内置的Tomcat容器和Spring MVC架构天然适合处理售票系统的高频短事务
- Vue的响应式数据绑定和组件化开发模式，能高效实现动态余票显示、座位选择等前端交互
- 前后端分离架构符合当前企业开发规范，毕业答辩时能体现技术前瞻性
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统架构设计
2.1 技术栈选型对比
| 技术方向 | 选型方案 | 淘汰方案 | 决策依据 |
|---|---|---|---|
| 后端框架 | SpringBoot 2.7.x | 传统SSM | 内嵌Tomcat简化部署，Starter依赖自动管理 |
| 前端框架 | Vue 3 + Element Plus | jQuery+Thymeleaf | 组合API更灵活，TypeScript支持更好 |
| 数据库 | MySQL 8.0 | MongoDB | 事务一致性要求高，需要ACID支持 |
| 缓存 | Redis | 无缓存 | 应对节假日购票高峰，减少数据库压力 |
| 消息队列 | RabbitMQ | Kafka | 订单超时取消等场景的延迟队列需求 |
2.2 核心业务模块划分
mermaid复制graph TD
A[用户服务] --> B(身份认证)
A --> C(购票历史)
D[车次服务] --> E(时刻表管理)
D --> F(余票计算)
G[订单服务] --> H(座位锁定)
G --> I(支付超时处理)
J[支付服务] --> K(微信/支付宝对接)
（注：实际提交时需替换为文字描述）
3. 关键实现细节
3.1 余票实时更新方案
采用Redis原子操作+数据库乐观锁的双重保障机制：
java复制// 伪代码示例
public boolean lockSeats(Long trainId, List<Integer> seats) {
String lockKey = "train:" + trainId;
return redisTemplate.execute(new RedisCallback<Boolean>() {
@Override
public Boolean doInRedis(RedisConnection connection) {
// WATCH监控关键键
connection.watch(lockKey.getBytes());
// 检查余量是否充足
Integer remain = Integer.parseInt(connection.get(lockKey.getBytes()));
if(remain >= seats.size()) {
// 开启事务
connection.multi();
connection.decrBy(lockKey.getBytes(), seats.size());
// 执行事务
List<Object> results = connection.exec();
return !results.isEmpty(); // 成功返回true
}
connection.unwatch();
return false;
}
});
}
3.2 前端座位选择交互
基于SVG实现可视化选座组件：
- 使用vue-draggable-next库处理拖拽选择
- 不同座位状态（可选/已售/锁定）通过CSS类动态切换
- 采用WebSocket保持座位状态实时同步
vue复制<template>
<div class="seat-map" @mousemove="handleHover">
<svg :viewBox="`0 0 ${width} ${height}`">
<g v-for="(row, i) in seats" :key="'row'+i">
<rect v-for="(seat, j) in row"
:key="'seat'+j"
:class="['seat', seat.status]"
@click="selectSeat(seat)"
:x="j * spacing"
:y="i * spacing"
width="20" height="20"/>
</g>
</svg>
</div>
</template>
4. 典型问题解决方案
4.1 超卖问题处理
通过分布式锁+库存预扣模式避免超卖：
- 用户下单时先扣减Redis库存
- 15分钟未支付则恢复库存
- 支付成功后更新数据库持久化库存
java复制// 库存恢复的延迟队列处理
@RabbitListener(queues = "order.timeout")
public void handleTimeoutOrder(OrderMessage message) {
String lockKey = "inventory:" + message.getTrainId();
if(redisLock.tryLock(lockKey, 10, TimeUnit.SECONDS)) {
try {
// 检查订单状态是否还是未支付
Order order = orderService.getById(message.getOrderId());
if(order.getStatus() == OrderStatus.UNPAID) {
// 恢复库存
redisTemplate.opsForValue().increment(
"train:stock:" + message.getTrainId(),
order.getTicketCount());
orderService.cancelOrder(message.getOrderId());
}
} finally {
redisLock.unlock(lockKey);
}
}
}
4.2 高并发场景优化
采用分级缓存策略：
- 第一层：本地缓存（Caffeine）存储静态车次信息
- 第二层：Redis集群缓存动态余票数据
- 数据库仅作为最终数据持久化层
压测指标对比（JMeter 1000并发）：
| 方案 | 平均响应时间 | 吞吐量 | 错误率 |
|---|---|---|---|
| 无缓存 | 1200ms | 45/sec | 12% |
| 单级Redis缓存 | 350ms | 210/sec | 0.5% |
| 两级缓存 | 180ms | 520/sec | 0% |
5. 部署与监控
5.1 容器化部署方案
使用Docker Compose编排服务：
yaml复制version: '3'
services:
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
volumes:
- mysql_data:/var/lib/mysql
redis:
image: redis:6-alpine
ports:
- "6379:6379"
app:
build: .
ports:
- "8080:8080"
depends_on:
- mysql
- redis
volumes:
mysql_data:
5.2 监控配置
- SpringBoot Actuator暴露健康检查端点
- Prometheus采集JVM指标
- Grafana展示关键监控看板
关键监控指标：
- 订单创建QPS
- 平均响应时间
- JVM内存使用率
- 数据库连接池活跃连接数
6. 毕业设计答辩要点
6.1 技术深度展示建议
- 重点讲解分布式锁的实现原理
- 演示JMeter压测结果对比
- 分析数据库事务隔离级别的选择依据
6.2 常见答辩问题准备
Q：为什么选用RabbitMQ而不是Kafka？
A：我们的消息量级在万级/天，且需要延迟队列功能。RabbitMQ的TTL+死信队列机制更符合需求，而Kafka更适合日志类大数据量场景。
Q：如何保证支付成功后的数据一致性？
A：采用本地事务表+定时任务补偿机制。支付回调时先记录事务日志，再异步更新订单状态，失败任务会进入重试队列。
7. 项目扩展方向
- 智能推荐：基于用户历史购票记录推荐相似车次
- 动态定价：根据供需关系调整票价
- 多交通联运：整合大巴、飞机票务
我在开发过程中特别推荐使用Arthas进行线上诊断，它的watch命令能实时观察余票扣减方法的参数和返回值，极大提升了并发问题排查效率。另外，前端使用Vue Devtools的Time Travel功能可以完美复现用户操作路径，这对调试复杂选座交互非常有帮助。