1. 项目概述与核心价值
铁路订票系统作为现代交通服务的重要基础设施，其数字化升级直接影响着数亿旅客的出行体验。这个毕业设计项目选择开发基于Web的铁路订票管理系统，本质上是在解决票务服务从传统窗口模式向互联网化转型的核心痛点——如何通过技术手段实现票务资源的公平分配、高效管理和实时同步。
我参与过多个交通行业的IT系统改造项目，深知这类系统的复杂性不仅在于技术实现，更在于对业务规则的精准建模。一个合格的铁路订票系统必须同时满足：高并发场景下的系统稳定性（春运期间12306日均PV超过1500亿次）、票务库存的实时准确性（避免一票多卖）、业务流程的合规性（学生票验证、退改签规则等）。这些需求使得系统设计远比表面看到的"查询-下单-支付"流程复杂得多。
2. 系统架构设计解析
2.1 技术栈选型考量
前端采用Vue.js+ElementUI的组合，这个选择基于三个实际考量：
- 组件化开发模式适合票务系统这种表单密集型的应用（车次查询、订单填写等页面包含大量交互组件）
- 相比React，Vue的学习曲线更适合毕业设计的时间约束
- ElementUI提供的表单验证、日期选择器等组件能直接满足车票查询的日期范围选择需求
后端选择Spring Boot框架，关键优势在于：
- 内置Tomcat简化部署，这对没有运维经验的毕业生很友好
- Spring Data JPA可以快速实现票务数据的CRUD操作
- 通过Spring Security可以相对简单地实现用户认证和权限控制
数据库选用MySQL 8.0，主要考虑其：
- 事务处理能力（保证售票过程的ACID特性）
- 对JSON格式的支持（便于存储动态的座位信息）
- 开源特性避免商业授权问题
2.2 高并发解决方案设计
针对订票系统最核心的"库存超卖"问题，项目实现了三级防护机制：
- 数据库层面：
sql复制UPDATE tickets
SET remain = remain - 1
WHERE train_id = ? AND date = ? AND remain > 0
通过WHERE条件中的余票检查实现原子性扣减
- 应用层分布式锁：
java复制// 使用Redisson实现分布式锁
RLock lock = redissonClient.getLock("ticket:"+trainId+":"+date);
try {
lock.lock();
// 执行库存操作
} finally {
lock.unlock();
}
- 前端限流措施：
- 提交订单按钮点击后立即禁用，防止重复提交
- 使用验证码机制防止机器人刷票
3. 核心业务模块实现
3.1 车票库存模型设计
采用"车次+日期+座位类型"的三维库存模型，数据库表关键字段如下：
| 字段名 | 类型 | 说明 |
|---|---|---|
| train_id | VARCHAR(20) | 车次编号如G123 |
| depart_date | DATE | 出发日期 |
| seat_type | ENUM | 座位类型（一等座/二等座等） |
| total | INT | 总座位数 |
| remain | INT | 剩余票数 |
| price | DECIMAL(10,2) | 票价 |
特别需要注意的是，实际铁路系统会采用更复杂的"席位库"模型（具体到每个车厢座位），但作为毕业设计，这种简化模型已经足够演示核心业务逻辑。
3.2 订单状态机设计
订单生命周期管理是系统的另一核心，状态转换规则如下：
mermaid复制stateDiagram-v2
[*] --> PENDING_PAYMENT
PENDING_PAYMENT --> PAID: 支付成功
PENDING_PAYMENT --> CANCELLED: 用户取消
PAID --> REFUNDED: 申请退票
PAID --> COMPLETED: 已乘车
对应的状态变更代码实现：
java复制public enum OrderStatus {
PENDING_PAYMENT("待支付", Arrays.asList("PAID", "CANCELLED")),
PAID("已支付", Arrays.asList("REFUNDED", "COMPLETED")),
// 其他状态...
private final List<String> allowedNextStates;
public boolean canTransferTo(String nextState) {
return allowedNextStates.contains(nextState);
}
}
4. 关键问题与解决方案
4.1 余票缓存一致性
采用"数据库+Redis"的双写策略，但需要特别注意缓存更新的时序问题：
- 查询流程：
- 先查Redis，命中则返回
- 未命中则查DB并回填Redis，设置5秒过期
- 更新流程：
- 先更新数据库
- 再删除Redis缓存（而非更新，避免并发写导致脏数据）
重要提示：永远不要在Redis中执行复杂的票务计算，只将其作为快速查询的缓存层
4.2 支付超时处理
通过定时任务扫描待支付订单：
java复制@Scheduled(cron = "0 */5 * * * ?")
public void cancelUnpaidOrders() {
List<Order> unpaidOrders = orderRepository.findByStatusAndCreateTimeBefore(
OrderStatus.PENDING_PAYMENT,
LocalDateTime.now().minusMinutes(30));
unpaidOrders.forEach(order -> {
order.cancel();
ticketService.releaseSeat(order);
orderRepository.save(order);
});
}
5. 部署与测试要点
5.1 最小化生产部署方案
对于毕业设计演示环境，推荐以下配置：
- 服务器：1核2G云服务器（学生优惠约50元/月）
- 中间件：
- Nginx：前端部署和反向代理
- MySQL 8.0：主数据库
- Redis：缓存和分布式锁
- 启动脚本：
bash复制# 后端启动
nohup java -jar railway-ticket.jar --spring.profiles.active=prod &
# 前端部署
npm run build
cp -r dist/* /usr/share/nginx/html/
5.2 压力测试建议
使用JMeter模拟以下典型场景：
- 车次查询：100并发持续5分钟
- 下单流程：50并发，思考时间3秒
- 支付回调：模拟第三方支付平台回调
重点关注指标：
- 查询接口的99线响应时间
- 下单失败率
- MySQL连接池使用率
6. 毕业设计进阶建议
如果想在答辩中获得更好表现，可以考虑：
- 增加可视化监控：
- 使用Prometheus+Grafana监控系统关键指标
- 特别关注"库存余量"和"订单创建速率"的关联曲线
- 实现简单的推荐算法：
python复制# 基于车次热度的简单推荐
def recommend_trains(user):
hot_trains = Ticket.objects.filter(
depart_date=user.preferred_date
).annotate(
orders_count=Count('orders')
).order_by('-orders_count')[:5]
return hot_trains
- 安全加固措施：
- 接口防刷：使用Guava RateLimiter实现限流
- SQL注入防护：始终使用预编译语句
- XSS防护：前端使用DOMPurify过滤输入
这个项目最值得深入的不是技术本身，而是理解如何将复杂的业务规则转化为可靠的系统设计。我在第一次实现退票手续费计算时，就因为没有吃透铁路总局的阶梯退费规则（48小时以上扣5%，24-48小时扣10%等），导致产生了严重的逻辑漏洞。后来通过设计规则引擎才彻底解决这个问题：
java复制public class RefundCalculator {
public BigDecimal calculate(Order order, LocalDateTime refundTime) {
long hours = Duration.between(refundTime, order.getDepartTime()).toHours();
if (hours >= 48) {
return order.getAmount().multiply(new BigDecimal("0.05"));
} else if (hours >= 24) {
return order.getAmount().multiply(new BigDecimal("0.10"));
} else {
return order.getAmount().multiply(new BigDecimal("0.20"));
}
}
}