1. 项目背景与核心价值航空票务系统作为现代交通出行的重要基础设施其技术实现方案直接影响着数百万旅客的出行体验。传统票务系统面临高并发访问、复杂业务逻辑和数据一致性等核心挑战而基于SSMSpringSpringMVCMyBatis框架的解决方案恰好能平衡开发效率与系统性能。我在实际开发中发现一个成熟的航班订票系统需要处理以下典型场景高峰时段每秒上千次的查询请求、座位库存的实时精确控制、支付与出票的原子性操作。SSM框架组合中Spring的IoC容器管理着近200个业务BeanMyBatis的二级缓存使热门航线查询响应时间控制在50ms内这些技术细节直接决定了系统能否承受真实业务压力。2. 技术架构设计解析2.1 分层架构实现系统采用经典四层架构设计表现层SpringMVC处理前端请求配置了自定义的日期转换器DateTimeFormat注解无法满足多时区需求业务层Spring事务管理采用Transactional(isolationREPEATABLE_READ)级别防止超卖持久层MyBatis动态SQL处理80余种组合查询条件数据层MySQL采用主从复制读写分离配置通过AbstractRoutingDataSource实现2.2 数据库关键设计机票系统的数据库设计有三大核心难点座位库存管理采用flight_seat表与seat_lock表分离设计通过状态机模式enum SeatStatus控制价格策略建立price_rule表实现动态定价包含提前天数、剩余座位数等15个影响因子事务控制支付流程使用SELECT...FOR UPDATE实现悲观锁配合本地消息表保证最终一致性CREATE TABLE flight_seat ( id BIGINT PRIMARY KEY AUTO_INCREMENT, flight_no VARCHAR(20) NOT NULL COMMENT 航班号, seat_class ENUM(FIRST,BUSINESS,ECONOMY) NOT NULL, total_count INT NOT NULL COMMENT 总座位数, available_count INT NOT NULL COMMENT 可售数量, version INT DEFAULT 0 COMMENT 乐观锁版本号 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;3. 核心业务实现细节3.1 余票查询优化通过Redis缓存热点航班数据采用分段缓存策略未来3天内的航班缓存全量座位信息30秒刷新3-15天的航班缓存各舱位余量5分钟刷新15天后的航班只缓存基础信息public ListFlightVO queryFlights(FlightQueryDTO dto) { String cacheKey buildCacheKey(dto); ListFlightVO cached redisTemplate.opsForValue().get(cacheKey); if (cached ! null) { return cached; } // 缓存未命中时的数据库查询 ListFlight flights flightMapper.selectByCondition(dto); ListFlightVO result convertToVO(flights); // 根据时间范围设置不同过期时间 Duration ttl determineTTL(dto.getDepartureDate()); redisTemplate.opsForValue().set(cacheKey, result, ttl); return result; }3.2 订票分布式事务采用TCCTry-Confirm-Cancel模式处理分布式事务Try阶段冻结座位update seat set statusLOCKEDConfirm阶段支付成功后更新为已售需要处理网络幂等Cancel阶段超时未支付自动释放座位通过Quartz定时任务扫描重要提示必须实现冻结记录表seat_lock与业务表的双写一致性建议采用本地事务先写冻结表再更新余量4. 性能优化实战4.1 MyBatis二级缓存配置在mybatis-config.xml中配置settings setting namecacheEnabled valuetrue/ setting namelocalCacheScope valueSTATEMENT/ /settings !-- 在Mapper.xml中 -- cache evictionLRU flushInterval600000 size1024/实测效果热门航线查询QPS从120提升到2100平均响应时间从180ms降至25ms需注意及时清理缓存在增删改操作中添加CacheEvict4.2 连接池调优Druid连接池关键参数spring.datasource.druid.initial-size5 spring.datasource.druid.max-active50 spring.datasource.druid.min-idle10 spring.datasource.druid.max-wait3000 spring.datasource.druid.time-between-eviction-runs-millis600005. 典型问题排查实录5.1 座位超卖问题现象同一座位被多个订单占用 根因乐观锁版本号未正确传递 解决方案在Service方法添加synchronized关键字仅单机有效使用分布式锁Redisson实现RLock lock redissonClient.getLock(FLIGHT_LOCK:flightId); try { lock.lock(5, TimeUnit.SECONDS); // 业务逻辑 } finally { lock.unlock(); }5.2 支付状态同步延迟现象支付成功但订单状态未更新 处理方案引入RabbitMQ实现异步通知增加状态补偿任务每5分钟扫描待确认订单前端采用长轮询查询最新状态6. 安全防护措施6.1 防刷票机制IP限流Guava RateLimiter实现每分钟20次查询限制验证码在连续查询5次后触发图形验证黑名单对异常账号进行1小时访问限制6.2 SQL注入防护强制使用MyBatis参数绑定#{param}语法安装MyBatis插件拦截可疑SQLIntercepts(Signature(type StatementHandler.class, methodprepare, args{Connection.class,Integer.class})) public class SqlInjectInterceptor implements Interceptor { // 检测是否有非法字符 }7. 部署架构建议生产环境推荐配置前端Nginx负载均衡 静态资源缓存应用层Tomcat集群至少3节点缓存Redis哨兵模式1主2从数据库MySQL Group Replication3节点监控Prometheus Grafana监控JVM指标我在实际部署中发现Tomcat的以下参数对高并发场景至关重要server.tomcat.max-threads200 server.tomcat.accept-count100 server.tomcat.connection-timeout50008. 扩展优化方向机票价格预测基于历史数据训练LSTM模型智能推荐根据用户画像推荐增值服务多租户支持SAAS化改造需重构数据隔离方案全球化部署考虑时区与汇率自动转换经验之谈在开发初期就预留I18N字段长度如中文占3个字符避免后期数据库重构