
1. 项目概述汽车票网上预订系统是现代交通服务数字化转型的典型应用。这个基于SpringBoot的系统设计旨在解决传统线下购票模式存在的排队时间长、票务信息不透明、跨区域购票困难等痛点。我在实际开发中发现一个完善的票务系统不仅需要稳定的后台服务还要考虑高并发场景下的系统可靠性。2. 系统架构设计2.1 技术栈选型核心采用SpringBoot 2.7.x框架主要基于以下考虑内嵌Tomcat服务器简化部署自动配置特性大幅减少XML配置丰富的Starter依赖快速集成常用组件与Spring生态无缝衔接数据库选用MySQL 8.0因其事务支持完善对JSON数据类型良好支持成熟的集群方案缓存层使用Redis 6.x高频查询数据缓存如车次信息分布式锁实现秒杀场景下的库存控制2.2 微服务拆分系统按功能划分为四个微服务用户服务处理注册、登录、权限管理票务服务核心业务逻辑实现支付服务对接第三方支付平台调度服务与车站系统数据同步服务间通信采用RESTful API同步调用RabbitMQ异步消息OpenFeign服务调用3. 核心功能实现3.1 余票查询优化实现毫秒级响应是关键挑战。我们采用多级缓存策略Redis缓存热门线路数据设置5分钟过期本地缓存Caffeine存储车站基础信息数据库查询使用覆盖索引// 余票查询示例代码 Cacheable(value ticketCache, key #routeId) public TicketInfo queryTicket(Long routeId) { // 先查Redis String cacheKey ticket: routeId; String cached redisTemplate.opsForValue().get(cacheKey); if (cached ! null) { return JSON.parseObject(cached, TicketInfo.class); } // 查数据库 TicketInfo ticket ticketMapper.selectByRouteId(routeId); // 写入Redis redisTemplate.opsForValue().set( cacheKey, JSON.toJSONString(ticket), 5, TimeUnit.MINUTES); return ticket; }3.2 订单创建流程订单服务采用TCC模式保证事务一致性Try阶段预扣库存生成订单快照Confirm阶段确认支付后更新状态Cancel阶段超时未支付释放库存重要提示必须处理网络抖动导致的重复请求问题我们通过订单唯一号分布式锁解决4. 高并发处理4.1 秒杀场景设计春运期间热门线路会出现瞬时高并发我们采用令牌桶限流RateLimiter库存分段扣减避免单行记录竞争前端随机延迟提交分散请求峰值4.2 数据库优化MySQL层面采取的措施读写分离主从架构热点数据垂直拆分使用连接池控制并发连接数5. 安全防护5.1 防刷票机制用户行为分析同一IP/设备频繁操作验证码策略滑动验证短信验证购票频率限制自然日/小时维度5.2 数据加密敏感信息处理原则密码BCrypt加密存储身份证号AES对称加密通信数据HTTPS签名验证6. 运维监控6.1 健康检查集成SpringBoot Actuator提供服务健康状态线程池监控数据库连接池状态6.2 日志收集采用ELK栈实现Logback输出结构化日志Filebeat收集日志文件Kibana可视化分析7. 部署方案7.1 容器化部署Docker Compose编排服务version: 3 services: ticket-service: image: registry.example.com/ticket:1.0 ports: - 8080:8080 environment: - SPRING_PROFILES_ACTIVEprod depends_on: - redis - mysql redis: image: redis:6-alpine ports: - 6379:6379 mysql: image: mysql:8.0 environment: - MYSQL_ROOT_PASSWORDsecret ports: - 3306:33067.2 CI/CD流程Jenkins流水线关键步骤代码扫描SonarQube单元测试必须100%通过构建Docker镜像滚动更新到K8s集群8. 踩坑实录分布式事务问题现象支付成功但订单状态未更新原因网络分区导致MQ消息丢失解决增加事务日志表定时补偿任务缓存雪崩现象Redis集群宕机导致数据库被打挂解决引入多级缓存熔断降级策略日期处理坑错误直接使用LocalDateTime存储正确统一转为UTC时间戳存储教训所有时间字段必须明确时区这个项目让我深刻体会到票务系统看似简单实则需要在架构设计上考虑非常多的细节。特别是在高并发场景下一个小小的设计缺陷就可能引发连锁反应。建议开发类似系统时一定要提前做好压力测试和故障演练。