简介这份资源是基于Java的航空订票管理系统设计源码面向学习Java桌面开发、需要课程设计或毕业设计参考的学生与开发者帮助解决票务预订、退票、账户管理等业务场景的实现问题。压缩包共33个文件约2.87MB以17个Java源文件为核心配合10张png界面截图、1个sql建库脚本、1个MySQL连接jar包及readme说明覆盖登录注册、主界面、退票等模块源码按view、control、database等目录分层组织结构清晰便于二次开发。目前已有357人学习下载。读者可从中获得一套可直接运行的SwingJDBCMySQL 8.0完整项目理解事件处理、数据库连接封装与界面布局思路并借助截图与SQL脚本快速还原运行环境适合作为Java桌面应用入门与实战练习的参考范例。1. 从一份 Java 航空订票管理系统源码看清它到底解决什么问题航班座位是典型的稀缺资源同一时刻可能有几百个请求抢同一批座位超卖一张票的代价远高于普通电商订单。基于 Java 的航空订票管理系统设计源码核心要解决的就是「航班、座位、订单、支付」四件事在并发下的一致性以及后台运营人员能不能高效地排班、调价、退改签。它适合三类人正在做 Java 课程设计或毕业设计的学生需要一套能跑通、能讲清业务闭环的参考实现想练手 Spring Boot 全栈的初中级开发拿它当真实业务场景的练手项目以及需要快速搭一套内部票务原型的工程师直接复用领域模型和并发控制思路。源码本身不是终点能不能读懂座位锁定、订单状态机、库存扣减这几处关键设计才是这份源码值不值得投入的判断标准。2. 航空订票系统的领域模型怎么拆从航班到订单的四张核心表2.1 为什么先定实体边界再写代码拿到一份订票系统源码很多人第一反应是打开 Controller 看接口结果被一堆 DTO 绕晕。我的习惯是先看数据库表结构和实体类因为航空订票的业务复杂度几乎全在实体关系上。航班Flight是计划层描述某条航线在某个日期几点起飞、用什么机型舱位Cabin是销售层同一个航班分头等、经济各自有独立库存和价格座位Seat是物理层具体到 12A 这种编号订单Order是交易层关联乘客、舱位、支付状态。这四层如果混在一起后面退改签和超卖控制会非常痛苦。常见做法是把 Flight 和 Cabin 设计成一对多Cabin 持有totalSeats和availableSeats两个字段库存扣减只动 Cabin不直接动 Seat。Seat 表只在需要选座时使用和订单通过order_id关联。这样设计的好处是不选座的快速出票流程完全不碰 Seat 表减少锁竞争需要选座时再单独处理座位占用。下面是一个精简的实体关系定义用 JPA 注解表达。Entity Table(name flight) public class Flight { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private String flightNo; // 航班号如 CA1234 private String depAirport; // 出发机场三字码 private String arrAirport; // 到达机场三字码 private LocalDateTime depTime; // 计划起飞时间 private String aircraftType; // 机型影响座位布局 OneToMany(mappedBy flight, cascade CascadeType.ALL) private ListCabin cabins; } Entity Table(name cabin) public class Cabin { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; ManyToOne JoinColumn(name flight_id) private Flight flight; private String cabinCode; // F/C/Y头等/公务/经济 private Integer totalSeats; private Integer availableSeats; // 扣减库存的唯一入口 private BigDecimal price; Version private Integer version; // 乐观锁版本号 }这段代码的关键在Cabin上的Version。航空订票的库存扣减如果用悲观锁SELECT ... FOR UPDATE在高峰期会把数据库连接池打满用乐观锁配合重试吞吐量更高代价是冲突时需要业务层重试。availableSeats是唯一允许扣减的字段任何绕过它直接改 Seat 表的写法都会导致库存对不上。参数上cabinCode建议用单字符编码而不是中文方便索引和前端映射price用BigDecimal而不是double金额计算不能有浮点误差。2.2 订单状态机别让状态字段变成玄学订单表最容易翻车的地方是状态字段。我见过不少源码用status一个 int 表示所有情况结果退票、改签、支付超时全挤在一起查问题时只能靠猜。可靠的做法是定义明确的状态枚举和允许的迁移路径。典型状态包括PENDING_PAYMENT待支付、PAID已支付、TICKETED已出票、CANCELLED已取消、REFUNDED已退款。迁移规则是待支付只能到已支付或已取消已支付只能到已出票或已退款已出票只能到已退款。任何跨状态跳转都应在 Service 层拦截。public enum OrderStatus { PENDING_PAYMENT, PAID, TICKETED, CANCELLED, REFUNDED; // 定义合法迁移避免状态乱跳 public boolean canTransferTo(OrderStatus target) { switch (this) { case PENDING_PAYMENT: return target PAID || target CANCELLED; case PAID: return target TICKETED || target REFUNDED; case TICKETED: return target REFUNDED; default: return false; } } }在更新订单状态时先查当前状态调用canTransferTo校验再执行更新。这一步能挡掉大部分因为并发或前端重复提交导致的状态错乱。参数说明状态枚举建议存字符串而不是序号数据库里可读性更好排查问题时不用对照数字如果担心存储空间用VARCHAR(20)完全够用。订单表还应该有一个idempotent_key字段由前端生成唯一值防止用户连点两次提交产生两笔订单。2.3 航班查询的索引与分页航班查询是读多写少的场景但条件组合多出发地、目的地、日期、舱位。如果每个条件都建单列索引MySQL 可能选错索引。我的经验是建一个联合索引(dep_airport, arr_airport, dep_time)覆盖最常用的查询路径。日期范围查询放在最后因为范围条件后面的列用不上索引。分页用LIMIT offset, size在深分页时性能会下降航班查询通常只查某一天数据量可控但如果要做「未来七天最低价」这类功能建议用覆盖索引先查主键再回表。-- 联合索引顺序不能反 ALTER TABLE flight ADD INDEX idx_route_time (dep_airport, arr_airport, dep_time); -- 查询某天某航线走索引 SELECT f.flight_no, f.dep_time, c.cabin_code, c.price, c.available_seats FROM flight f JOIN cabin c ON c.flight_id f.id WHERE f.dep_airport PEK AND f.arr_airport SHA AND f.dep_time BETWEEN 2025-06-01 00:00:00 AND 2025-06-01 23:59:59 AND c.available_seats 0;注意available_seats 0这个条件放在 JOIN 之后它不参与索引过滤但能挡掉已售罄的舱位。如果查询频率很高可以在 Redis 里缓存航班基础信息和库存但库存扣减仍以数据库为准缓存只做展示。这一步的边界是缓存和数据库之间允许短暂不一致但扣减必须走数据库乐观锁。3. 用 Spring Boot 跑通订票主流程从选航班到出票的最小闭环3.1 项目分层与依赖选型一份能跑的 Java 航空订票管理系统源码通常用 Spring Boot Spring Data JPA MySQL Redis 这套组合。选 JPA 而不是 MyBatis 的原因是实体关系复杂JPA 的关联映射能省不少手写 SQL但如果团队更熟悉 MyBatis换成 MyBatis-Plus 也完全可行核心的库存扣减逻辑不变。Redis 用来做分布式锁和缓存不是必须单机部署可以用本地锁替代。下面是最小依赖配置。dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency /dependencies参数说明Spring Boot 版本建议 2.7.x 或 3.x3.x 需要 Java 17如果课程设计环境是 Java 8选 2.7.x。MySQL 驱动在 8.x 后包名变成com.mysql.cj.jdbc.Driver连接串要加serverTimezoneAsia/Shanghai否则时间字段会差 8 小时这是血泪经验。Redis 如果只是本地跑用默认配置即可生产环境要设密码和最大连接数。3.2 库存扣减的乐观锁实现与重试订票最核心的一步是扣库存。前面在 Cabin 上加了Version扣减时 JPA 会自动带上版本条件。如果两个线程同时读到 version1一个先更新成功 version 变成 2另一个更新时WHERE version1匹配不到抛OptimisticLockException。业务层需要捕获这个异常并重试重试次数一般设 3 次超过就返回「当前预订人数过多请稍后重试」。Service public class BookingService { Autowired private CabinRepository cabinRepository; // 扣减库存带重试 public boolean deductStock(Long cabinId, int count) { int retry 3; while (retry-- 0) { try { Cabin cabin cabinRepository.findById(cabinId) .orElseThrow(() - new RuntimeException(舱位不存在)); if (cabin.getAvailableSeats() count) { return false; // 库存不足不重试 } cabin.setAvailableSeats(cabin.getAvailableSeats() - count); cabinRepository.save(cabin); // 提交时校验 version return true; } catch (OptimisticLockingFailureException e) { // 版本冲突短暂等待后重试 try { Thread.sleep(50); } catch (InterruptedException ignored) {} } } return false; } }这段代码的逻辑说明先查舱位判断库存是否足够足够则扣减并保存。save触发 flush 时如果版本冲突会抛异常捕获后 sleep 50ms 再重试。参数上重试次数 3 次是经验值太多会拖长响应时间太少在高峰期容易失败。Thread.sleep在生产环境建议换成带随机抖动的退避避免多个线程同时重试再次冲突。注意这段代码必须在事务内执行否则save不会立即 flush版本冲突检测会延迟到事务提交重试逻辑就失效了。3.3 下单接口的幂等与超时取消用户点击「提交订单」时网络抖动可能导致重复请求。幂等键由前端生成放在请求头或参数里后端用 Redis 的SETNX做去重key 是幂等键过期时间设 10 分钟。如果SETNX返回 false说明已经处理过直接返回上次的结果。订单创建后进入待支付状态同时投递一个延迟消息可以用 Redis 的 zset 或 RabbitMQ 延迟队列30 分钟未支付则自动取消并回滚库存。public Order createOrder(Long cabinId, String idempotentKey) { // 幂等校验 Boolean success redisTemplate.opsForValue() .setIfAbsent(order:idem: idempotentKey, 1, 10, TimeUnit.MINUTES); if (Boolean.FALSE.equals(success)) { throw new RuntimeException(请勿重复提交); } // 扣库存 boolean deducted bookingService.deductStock(cabinId, 1); if (!deducted) { throw new RuntimeException(库存不足); } // 创建订单状态 PENDING_PAYMENT Order order new Order(); order.setStatus(OrderStatus.PENDING_PAYMENT); order.setIdempotentKey(idempotentKey); orderRepository.save(order); // 投递延迟消息30 分钟后检查支付状态 delayQueue.offer(order.getId(), 30 * 60 * 1000); return order; }参数说明幂等键过期时间 10 分钟要大于订单创建的最长耗时否则同一请求重试时 key 已过期去重失效。延迟消息的 30 分钟是行业常见值可根据航司规则调整。回滚库存时同样要走乐观锁不能直接UPDATE cabin SET available_seats available_seats 1否则和扣减逻辑不对称容易在并发下出错。4. 并发抢票下的坑超卖、重复订单、状态错乱怎么排查4.1 超卖库存扣成负数现象available_seats出现负数或者两个订单占用了同一个座位。原因通常有两种一是扣减时没用乐观锁或悲观锁两个线程同时读到 1 都减成 0二是扣减和订单创建不在同一事务扣减成功但订单创建失败库存没回滚。解决扣减必须走带版本号的更新且扣减和订单创建放在同一个Transactional方法里。如果用了 Redis 缓存库存缓存扣减和数据库扣减要保证最终一致建议以数据库为准缓存只做展示。4.2 重复订单用户连点两次现象同一个用户同一航班出现两笔待支付订单。原因前端没做防抖后端没做幂等。解决前端按钮点击后置灰后端用幂等键 RedisSETNX拦截。注意幂等键要由前端生成 UUID不能用用户 ID 航班 ID 这种可预测的值否则同一用户想买两张票会被误拦。如果业务允许同一用户买多张幂等键应该每次下单都不同只防重复提交不防正常多买。4.3 状态错乱已退款订单又变成已支付现象订单状态从 REFUNDED 跳回 PAID。原因支付回调接口没有校验当前状态直接覆盖。解决所有状态变更走canTransferTo校验支付回调里先查订单当前状态只有PENDING_PAYMENT才允许改成PAID。另外支付回调可能重复到达回调接口也要做幂等用支付流水号做唯一键。4.4 航班查询慢索引没走对现象按出发地、目的地、日期查询时响应超过 2 秒。原因联合索引顺序不对或者日期用了函数导致索引失效。解决用EXPLAIN看执行计划确保type不是ALL。联合索引把等值条件放前面范围条件放最后。如果查询条件里对dep_time用了DATE(dep_time) 2025-06-01索引会失效改成dep_time BETWEEN ... AND ...。4.5 定时任务重复执行库存被回滚两次现象超时未支付订单被取消后库存加了一次过一会儿又加了一次。原因定时任务在多实例部署时同时执行或者任务没有幂等。解决定时任务加分布式锁或者用数据库的UPDATE ... WHERE status PENDING_PAYMENT保证只有一个实例能改成功。回滚库存前先检查订单状态只有从PENDING_PAYMENT改成CANCELLED的那一次才回滚。5. 让这份源码真正可用的三个进阶技巧5.1 用状态机引擎替代手写 if-else订单状态少的时候手写canTransferTo没问题但如果后面要加改签、升舱、部分退票状态迁移会变成一张网。这时候可以引入 Spring StateMachine 或轻量的状态机库把状态和事件配置化。好处是新增状态时不用改 Service 代码只加配置。代价是学习成本课程设计阶段手写足够生产项目建议上状态机。5.2 库存扣减的压测验证方法写完扣减逻辑怎么确认没有超卖我的做法是写一个 JMeter 或 Gatling 脚本模拟 500 个并发请求抢 100 张票跑完后检查available_seats是否等于 0订单数是否等于 100。如果库存是负数或订单超过 100说明锁没生效。压测时注意数据库连接池要调大否则请求会堵在连接获取上测不出真正的并发问题。下面是一个简单的验证 SQL。-- 压测后检查库存应为 0订单数应为 100 SELECT available_seats FROM cabin WHERE id 1; SELECT COUNT(*) FROM order WHERE cabin_id 1 AND status ! CANCELLED;如果结果不对先看日志里有没有OptimisticLockingFailureException有的话说明重试次数不够或冲突太激烈没有的话检查事务边界可能是扣减和订单创建不在同一事务。5.3 从源码到可演示项目的收尾习惯一份源码能不能拿得出手差别往往在收尾。我一般会做三件事第一写一个data.sql初始化几条航班和舱位数据别人 clone 下来直接能跑不用手动造数据第二把application.yml里的数据库密码、Redis 地址抽成环境变量避免提交敏感信息第三在 README 里写清楚启动步骤和压测命令而不是只贴一张架构图。这三件事花不了半小时但能让源码从「能看」变成「能用」。我自己踩过的坑是早期项目直接提交了本地数据库配置换台机器就跑不起来后来养成用application-dev.yml和application-prod.yml分离的习惯省了很多后悔药。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是基于Java的航空订票管理系统设计源码面向学习Java桌面开发、需要课程设计或毕业设计参考的学生与开发者帮助解决票务预订、退票、账户管理等业务场景的实现问题。压缩包共33个文件约2.87MB以17个Java源文件为核心配合10张png界面截图、1个sql建库脚本、1个MySQL连接jar包及readme说明覆盖登录注册、主界面、退票等模块源码按view、control、database等目录分层组织结构清晰便于二次开发。目前已有357人学习下载。读者可从中获得一套可直接运行的SwingJDBCMySQL 8.0完整项目理解事件处理、数据库连接封装与界面布局思路并借助截图与SQL脚本快速还原运行环境适合作为Java桌面应用入门与实战练习的参考范例。1. 从一份 Java 航空订票管理系统源码看清它到底解决什么问题航班座位是典型的稀缺资源同一时刻可能有几百个请求抢同一批座位超卖一张票的代价远高于普通电商订单。基于 Java 的航空订票管理系统设计源码核心要解决的就是「航班、座位、订单、支付」四件事在并发下的一致性以及后台运营人员能不能高效地排班、调价、退改签。它适合三类人正在做 Java 课程设计或毕业设计的学生需要一套能跑通、能讲清业务闭环的参考实现想练手 Spring Boot 全栈的初中级开发拿它当真实业务场景的练手项目以及需要快速搭一套内部票务原型的工程师直接复用领域模型和并发控制思路。源码本身不是终点能不能读懂座位锁定、订单状态机、库存扣减这几处关键设计才是这份源码值不值得投入的判断标准。2. 航空订票系统的领域模型怎么拆从航班到订单的四张核心表2.1 为什么先定实体边界再写代码拿到一份订票系统源码很多人第一反应是打开 Controller 看接口结果被一堆 DTO 绕晕。我的习惯是先看数据库表结构和实体类因为航空订票的业务复杂度几乎全在实体关系上。航班Flight是计划层描述某条航线在某个日期几点起飞、用什么机型舱位Cabin是销售层同一个航班分头等、经济各自有独立库存和价格座位Seat是物理层具体到 12A 这种编号订单Order是交易层关联乘客、舱位、支付状态。这四层如果混在一起后面退改签和超卖控制会非常痛苦。常见做法是把 Flight 和 Cabin 设计成一对多Cabin 持有totalSeats和availableSeats两个字段库存扣减只动 Cabin不直接动 Seat。Seat 表只在需要选座时使用和订单通过order_id关联。这样设计的好处是不选座的快速出票流程完全不碰 Seat 表减少锁竞争需要选座时再单独处理座位占用。下面是一个精简的实体关系定义用 JPA 注解表达。Entity Table(name flight) public class Flight { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private String flightNo; // 航班号如 CA1234 private String depAirport; // 出发机场三字码 private String arrAirport; // 到达机场三字码 private LocalDateTime depTime; // 计划起飞时间 private String aircraftType; // 机型影响座位布局 OneToMany(mappedBy flight, cascade CascadeType.ALL) private ListCabin cabins; } Entity Table(name cabin) public class Cabin { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; ManyToOne JoinColumn(name flight_id) private Flight flight; private String cabinCode; // F/C/Y头等/公务/经济 private Integer totalSeats; private Integer availableSeats; // 扣减库存的唯一入口 private BigDecimal price; Version private Integer version; // 乐观锁版本号 }这段代码的关键在Cabin上的Version。航空订票的库存扣减如果用悲观锁SELECT ... FOR UPDATE在高峰期会把数据库连接池打满用乐观锁配合重试吞吐量更高代价是冲突时需要业务层重试。availableSeats是唯一允许扣减的字段任何绕过它直接改 Seat 表的写法都会导致库存对不上。参数上cabinCode建议用单字符编码而不是中文方便索引和前端映射price用BigDecimal而不是double金额计算不能有浮点误差。2.2 订单状态机别让状态字段变成玄学订单表最容易翻车的地方是状态字段。我见过不少源码用status一个 int 表示所有情况结果退票、改签、支付超时全挤在一起查问题时只能靠猜。可靠的做法是定义明确的状态枚举和允许的迁移路径。典型状态包括PENDING_PAYMENT待支付、PAID已支付、TICKETED已出票、CANCELLED已取消、REFUNDED已退款。迁移规则是待支付只能到已支付或已取消已支付只能到已出票或已退款已出票只能到已退款。任何跨状态跳转都应在 Service 层拦截。public enum OrderStatus { PENDING_PAYMENT, PAID, TICKETED, CANCELLED, REFUNDED; // 定义合法迁移避免状态乱跳 public boolean canTransferTo(OrderStatus target) { switch (this) { case PENDING_PAYMENT: return target PAID || target CANCELLED; case PAID: return target TICKETED || target REFUNDED; case TICKETED: return target REFUNDED; default: return false; } } }在更新订单状态时先查当前状态调用canTransferTo校验再执行更新。这一步能挡掉大部分因为并发或前端重复提交导致的状态错乱。参数说明状态枚举建议存字符串而不是序号数据库里可读性更好排查问题时不用对照数字如果担心存储空间用VARCHAR(20)完全够用。订单表还应该有一个idempotent_key字段由前端生成唯一值防止用户连点两次提交产生两笔订单。2.3 航班查询的索引与分页航班查询是读多写少的场景但条件组合多出发地、目的地、日期、舱位。如果每个条件都建单列索引MySQL 可能选错索引。我的经验是建一个联合索引(dep_airport, arr_airport, dep_time)覆盖最常用的查询路径。日期范围查询放在最后因为范围条件后面的列用不上索引。分页用LIMIT offset, size在深分页时性能会下降航班查询通常只查某一天数据量可控但如果要做「未来七天最低价」这类功能建议用覆盖索引先查主键再回表。-- 联合索引顺序不能反 ALTER TABLE flight ADD INDEX idx_route_time (dep_airport, arr_airport, dep_time); -- 查询某天某航线走索引 SELECT f.flight_no, f.dep_time, c.cabin_code, c.price, c.available_seats FROM flight f JOIN cabin c ON c.flight_id f.id WHERE f.dep_airport PEK AND f.arr_airport SHA AND f.dep_time BETWEEN 2025-06-01 00:00:00 AND 2025-06-01 23:59:59 AND c.available_seats 0;注意available_seats 0这个条件放在 JOIN 之后它不参与索引过滤但能挡掉已售罄的舱位。如果查询频率很高可以在 Redis 里缓存航班基础信息和库存但库存扣减仍以数据库为准缓存只做展示。这一步的边界是缓存和数据库之间允许短暂不一致但扣减必须走数据库乐观锁。3. 用 Spring Boot 跑通订票主流程从选航班到出票的最小闭环3.1 项目分层与依赖选型一份能跑的 Java 航空订票管理系统源码通常用 Spring Boot Spring Data JPA MySQL Redis 这套组合。选 JPA 而不是 MyBatis 的原因是实体关系复杂JPA 的关联映射能省不少手写 SQL但如果团队更熟悉 MyBatis换成 MyBatis-Plus 也完全可行核心的库存扣减逻辑不变。Redis 用来做分布式锁和缓存不是必须单机部署可以用本地锁替代。下面是最小依赖配置。dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency /dependencies参数说明Spring Boot 版本建议 2.7.x 或 3.x3.x 需要 Java 17如果课程设计环境是 Java 8选 2.7.x。MySQL 驱动在 8.x 后包名变成com.mysql.cj.jdbc.Driver连接串要加serverTimezoneAsia/Shanghai否则时间字段会差 8 小时这是血泪经验。Redis 如果只是本地跑用默认配置即可生产环境要设密码和最大连接数。3.2 库存扣减的乐观锁实现与重试订票最核心的一步是扣库存。前面在 Cabin 上加了Version扣减时 JPA 会自动带上版本条件。如果两个线程同时读到 version1一个先更新成功 version 变成 2另一个更新时WHERE version1匹配不到抛OptimisticLockException。业务层需要捕获这个异常并重试重试次数一般设 3 次超过就返回「当前预订人数过多请稍后重试」。Service public class BookingService { Autowired private CabinRepository cabinRepository; // 扣减库存带重试 public boolean deductStock(Long cabinId, int count) { int retry 3; while (retry-- 0) { try { Cabin cabin cabinRepository.findById(cabinId) .orElseThrow(() - new RuntimeException(舱位不存在)); if (cabin.getAvailableSeats() count) { return false; // 库存不足不重试 } cabin.setAvailableSeats(cabin.getAvailableSeats() - count); cabinRepository.save(cabin); // 提交时校验 version return true; } catch (OptimisticLockingFailureException e) { // 版本冲突短暂等待后重试 try { Thread.sleep(50); } catch (InterruptedException ignored) {} } } return false; } }这段代码的逻辑说明先查舱位判断库存是否足够足够则扣减并保存。save触发 flush 时如果版本冲突会抛异常捕获后 sleep 50ms 再重试。参数上重试次数 3 次是经验值太多会拖长响应时间太少在高峰期容易失败。Thread.sleep在生产环境建议换成带随机抖动的退避避免多个线程同时重试再次冲突。注意这段代码必须在事务内执行否则save不会立即 flush版本冲突检测会延迟到事务提交重试逻辑就失效了。3.3 下单接口的幂等与超时取消用户点击「提交订单」时网络抖动可能导致重复请求。幂等键由前端生成放在请求头或参数里后端用 Redis 的SETNX做去重key 是幂等键过期时间设 10 分钟。如果SETNX返回 false说明已经处理过直接返回上次的结果。订单创建后进入待支付状态同时投递一个延迟消息可以用 Redis 的 zset 或 RabbitMQ 延迟队列30 分钟未支付则自动取消并回滚库存。public Order createOrder(Long cabinId, String idempotentKey) { // 幂等校验 Boolean success redisTemplate.opsForValue() .setIfAbsent(order:idem: idempotentKey, 1, 10, TimeUnit.MINUTES); if (Boolean.FALSE.equals(success)) { throw new RuntimeException(请勿重复提交); } // 扣库存 boolean deducted bookingService.deductStock(cabinId, 1); if (!deducted) { throw new RuntimeException(库存不足); } // 创建订单状态 PENDING_PAYMENT Order order new Order(); order.setStatus(OrderStatus.PENDING_PAYMENT); order.setIdempotentKey(idempotentKey); orderRepository.save(order); // 投递延迟消息30 分钟后检查支付状态 delayQueue.offer(order.getId(), 30 * 60 * 1000); return order; }参数说明幂等键过期时间 10 分钟要大于订单创建的最长耗时否则同一请求重试时 key 已过期去重失效。延迟消息的 30 分钟是行业常见值可根据航司规则调整。回滚库存时同样要走乐观锁不能直接UPDATE cabin SET available_seats available_seats 1否则和扣减逻辑不对称容易在并发下出错。4. 并发抢票下的坑超卖、重复订单、状态错乱怎么排查4.1 超卖库存扣成负数现象available_seats出现负数或者两个订单占用了同一个座位。原因通常有两种一是扣减时没用乐观锁或悲观锁两个线程同时读到 1 都减成 0二是扣减和订单创建不在同一事务扣减成功但订单创建失败库存没回滚。解决扣减必须走带版本号的更新且扣减和订单创建放在同一个Transactional方法里。如果用了 Redis 缓存库存缓存扣减和数据库扣减要保证最终一致建议以数据库为准缓存只做展示。4.2 重复订单用户连点两次现象同一个用户同一航班出现两笔待支付订单。原因前端没做防抖后端没做幂等。解决前端按钮点击后置灰后端用幂等键 RedisSETNX拦截。注意幂等键要由前端生成 UUID不能用用户 ID 航班 ID 这种可预测的值否则同一用户想买两张票会被误拦。如果业务允许同一用户买多张幂等键应该每次下单都不同只防重复提交不防正常多买。4.3 状态错乱已退款订单又变成已支付现象订单状态从 REFUNDED 跳回 PAID。原因支付回调接口没有校验当前状态直接覆盖。解决所有状态变更走canTransferTo校验支付回调里先查订单当前状态只有PENDING_PAYMENT才允许改成PAID。另外支付回调可能重复到达回调接口也要做幂等用支付流水号做唯一键。4.4 航班查询慢索引没走对现象按出发地、目的地、日期查询时响应超过 2 秒。原因联合索引顺序不对或者日期用了函数导致索引失效。解决用EXPLAIN看执行计划确保type不是ALL。联合索引把等值条件放前面范围条件放最后。如果查询条件里对dep_time用了DATE(dep_time) 2025-06-01索引会失效改成dep_time BETWEEN ... AND ...。4.5 定时任务重复执行库存被回滚两次现象超时未支付订单被取消后库存加了一次过一会儿又加了一次。原因定时任务在多实例部署时同时执行或者任务没有幂等。解决定时任务加分布式锁或者用数据库的UPDATE ... WHERE status PENDING_PAYMENT保证只有一个实例能改成功。回滚库存前先检查订单状态只有从PENDING_PAYMENT改成CANCELLED的那一次才回滚。5. 让这份源码真正可用的三个进阶技巧5.1 用状态机引擎替代手写 if-else订单状态少的时候手写canTransferTo没问题但如果后面要加改签、升舱、部分退票状态迁移会变成一张网。这时候可以引入 Spring StateMachine 或轻量的状态机库把状态和事件配置化。好处是新增状态时不用改 Service 代码只加配置。代价是学习成本课程设计阶段手写足够生产项目建议上状态机。5.2 库存扣减的压测验证方法写完扣减逻辑怎么确认没有超卖我的做法是写一个 JMeter 或 Gatling 脚本模拟 500 个并发请求抢 100 张票跑完后检查available_seats是否等于 0订单数是否等于 100。如果库存是负数或订单超过 100说明锁没生效。压测时注意数据库连接池要调大否则请求会堵在连接获取上测不出真正的并发问题。下面是一个简单的验证 SQL。-- 压测后检查库存应为 0订单数应为 100 SELECT available_seats FROM cabin WHERE id 1; SELECT COUNT(*) FROM order WHERE cabin_id 1 AND status ! CANCELLED;如果结果不对先看日志里有没有OptimisticLockingFailureException有的话说明重试次数不够或冲突太激烈没有的话检查事务边界可能是扣减和订单创建不在同一事务。5.3 从源码到可演示项目的收尾习惯一份源码能不能拿得出手差别往往在收尾。我一般会做三件事第一写一个data.sql初始化几条航班和舱位数据别人 clone 下来直接能跑不用手动造数据第二把application.yml里的数据库密码、Redis 地址抽成环境变量避免提交敏感信息第三在 README 里写清楚启动步骤和压测命令而不是只贴一张架构图。这三件事花不了半小时但能让源码从「能看」变成「能用」。我自己踩过的坑是早期项目直接提交了本地数据库配置换台机器就跑不起来后来养成用application-dev.yml和application-prod.yml分离的习惯省了很多后悔药。希望帮到你。本文还有配套的精品资源点击获取
