尧图网页设计 
简介本资源为基于Java开发的演唱会在线购票系统设计源码面向学习Java Web开发、课程设计或毕业设计的学生与开发者帮助理解在线购票业务从用户管理、票务查询到订单处理的核心实现。压缩包共37个文件约2.1MB包含13个Java源文件承载业务逻辑10个class编译产物6个XML配置文件用于数据源与环境参数设置另有SQL建表脚本、properties数据库连接配置、JAR依赖包及readme说明目录结构清晰便于按模块阅读与二次开发。目前已有91人学习下载。源码采用典型分层设计涵盖用户注册登录、演唱会信息浏览、选座支付与订单管理等模块并附带数据库脚本与依赖库可直接导入IDE运行调试适合作为在线购票系统设计与实现的完整参考范例帮助读者快速掌握Java项目结构、数据库操作与MVC分层思路。1. 演唱会在线购票系统为什么 Java 技术栈是这类高并发场景的稳妥选择抢票这件事做过的人都知道有多玄学。开票那一秒几十万人同时点同一个按钮库存只有几千张系统要么卡死要么超卖要么订单重复。演唱会在线购票系统的核心难点从来不是页面好不好看而是高并发下的库存一致性和订单幂等。这个标题指向的是一套用 Java 开发的在线购票系统源码适合有一定 Java 基础、想通过一个完整项目把 SSM 或 Spring Boot 用起来的开发者也适合课程设计或毕业设计阶段需要落地案例的同学。它要解决的问题很具体用户浏览演出场次、选座或选票档、下单锁库存、支付回调、超时释放。整条链路涉及数据库事务、缓存、消息队列和定时任务是一个能把 Java 后端主要知识点串起来的场景。相比简单的增删改查管理系统购票系统的技术密度更高面试时也更容易讲出深度。下面我会按实际落地顺序把技术选型、库表设计、核心代码和踩坑经验拆开讲清楚。2. 技术选型与工程结构从单体到可扩展的购票后端2.1 为什么选 Spring Boot MyBatis 而不是纯 Servlet常见做法是用 Spring Boot 2.x 搭配 MyBatis-Plus前端可以是 Thymeleaf 服务端渲染也可以前后端分离用 Vue。选 Spring Boot 的理由很直接内置 Tomcat、自动装配、starter 依赖管理能把精力放在业务逻辑而不是 XML 配置上。MyBatis 相比 JPA 更适合购票系统因为库存扣减这类操作需要手写 SQL 精确控制比如UPDATE ticket_stock SET stock stock - 1 WHERE stock 0这种带条件的原子更新用 ORM 自动生成反而不好控制。工程结构我一般会这样分concert-ticket/ ├── ticket-common/ # 通用工具、常量、统一返回体 ├── ticket-dao/ # 实体类、Mapper 接口、XML ├── ticket-service/ # 业务逻辑、事务控制 ├── ticket-web/ # Controller、拦截器、参数校验 └── ticket-job/ # 定时任务超时订单释放分层的好处是定时任务模块可以独立部署避免和 Web 请求抢资源。如果只是课程设计合并成一个模块也能跑但面试时讲出分层思路是加分项。2.2 数据库表设计五张核心表撑起整条链路购票系统的表不用多但每张都要设计到位。下面是我实际用过的核心表结构表名作用关键字段concert演出场次id, name, venue, show_time, statusticket_category票档id, concert_id, price, total_stockticket_stock库存独立表id, category_id, stock, versionticket_order订单id, order_no, user_id, category_id, quantity, status, expire_timepayment_record支付记录id, order_no, pay_time, amount, status把库存单独拆成ticket_stock表而不是放在ticket_category里是为了减少行锁竞争。票档信息读多写少库存写多读多分开后更新库存时不会锁住票档的查询。订单状态用枚举值管理0-待支付、1-已支付、2-已取消、3-已退款。expire_time字段记录订单超时时间默认下单后 15 分钟定时任务扫描这个字段来释放库存。2.3 库存扣减的两种方案与选择依据库存扣减是购票系统最容易翻车的地方。常见两种方案方案一数据库乐观锁。在ticket_stock表加version字段扣减时带上版本号UPDATE ticket_stock SET stock stock - #{quantity}, version version 1 WHERE category_id #{categoryId} AND stock #{quantity} AND version #{version}影响行数为 0 就说明被别人抢先改了重试或直接返回失败。优点是实现简单、不依赖额外组件缺点是并发高时重试次数多数据库压力大。方案二Redis 预扣减 数据库异步落库。开票前把库存加载到 Redis扣减用 Lua 脚本保证原子性成功后发消息到 MQ由消费者慢慢写数据库。优点是抗并发能力强缺点是引入 Redis 和 MQ复杂度和运维成本上升还要处理缓存和数据库的一致性。我的建议是课程设计或中小规模用方案一就够了把乐观锁和重试逻辑写清楚如果标题里强调高并发或者你想在面试里讲亮点再上方案二。不要为了炫技在数据量只有几百的时候硬上 Redis反而容易出数据不一致的问题。3. 核心功能落地下单、锁库存、支付回调的代码实现3.1 下单接口参数校验与防重复提交下单是整条链路的入口必须做好参数校验和幂等。用户可能因为网络卡顿连点两次也可能恶意刷单。我一般会在 Controller 层加一个基于 Redis 的防重令牌或者用userId categoryId做唯一索引兜底。PostMapping(/order/create) public Result createOrder(RequestBody Valid OrderCreateDTO dto, HttpServletRequest request) { Long userId getCurrentUserId(request); // 1. 参数校验数量必须大于0且不超过限购 if (dto.getQuantity() 0 || dto.getQuantity() 4) { return Result.fail(购票数量不合法); } // 2. 防重复提交同一用户同一票档5秒内只能提交一次 String lockKey order:lock: userId : dto.getCategoryId(); Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, 5, TimeUnit.SECONDS); if (Boolean.FALSE.equals(locked)) { return Result.fail(操作过于频繁请稍后再试); } try { // 3. 调用Service层创建订单 String orderNo orderService.createOrder(userId, dto); return Result.success(orderNo); } finally { // 注意这里不删锁让锁自然过期避免误删别人的锁 } }逻辑说明setIfAbsent对应 Redis 的SETNX设置 5 秒过期是防止死锁。参数校验用 JSR-303 注解在 DTO 上完成限购数量根据业务定演唱会一般每人限购 2 到 4 张。finally里不主动删锁是因为如果业务执行时间超过锁过期时间删锁可能删掉其他线程刚加的锁让锁自然过期更安全。参数方面quantity建议在 DTO 上用Min(1)和Max(4)双重限制categoryId必须校验是否存在且属于当前在售场次。3.2 库存扣减与订单创建的事务边界下单的核心是在一个事务里完成「扣库存 创建订单」。这两步必须同时成功或同时失败否则会出现扣了库存没订单或者有订单没扣库存。Transactional(rollbackFor Exception.class) public String createOrder(Long userId, OrderCreateDTO dto) { // 1. 查询库存带版本号 TicketStock stock stockMapper.selectByCategoryId(dto.getCategoryId()); if (stock null || stock.getStock() dto.getQuantity()) { throw new BizException(库存不足); } // 2. 乐观锁扣减库存 int affected stockMapper.deductStock( dto.getCategoryId(), dto.getQuantity(), stock.getVersion()); if (affected 0) { throw new BizException(当前购票人数过多请重试); } // 3. 创建订单 TicketOrder order new TicketOrder(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setCategoryId(dto.getCategoryId()); order.setQuantity(dto.getQuantity()); order.setStatus(OrderStatus.UNPAID.getCode()); order.setExpireTime(LocalDateTime.now().plusMinutes(15)); orderMapper.insert(order); return order.getOrderNo(); }逻辑说明Transactional的rollbackFor Exception.class确保任何异常都回滚包括受检异常。扣库存用乐观锁affected 0说明版本号对不上直接抛异常让事务回滚。订单号生成建议用「时间戳 用户ID后四位 随机数」不要用自增 ID 直接暴露。参数说明expire_time设为 15 分钟后这个值要和定时任务的扫描周期匹配。如果定时任务每分钟跑一次15 分钟意味着用户有 14 到 15 分钟的支付时间可以接受。如果设成 5 分钟用户刚打开支付页面就超时了体验很差。3.3 支付回调与超时订单释放支付回调是第三方支付平台通知我们支付结果必须做签名验证和幂等处理。超时释放则是定时任务扫描expire_time小于当前时间且状态为待支付的订单把库存加回去。// 支付回调 PostMapping(/pay/callback) public String payCallback(RequestBody PayCallbackDTO dto) { // 1. 验签防止伪造回调 if (!payService.verifySign(dto)) { return FAIL; } // 2. 幂等根据订单号查状态已支付直接返回成功 TicketOrder order orderMapper.selectByOrderNo(dto.getOrderNo()); if (order.getStatus() OrderStatus.PAID.getCode()) { return SUCCESS; } // 3. 更新订单状态和支付记录 orderService.markPaid(dto.getOrderNo(), dto.getPayTime()); return SUCCESS; }// 定时任务每分钟执行一次 Scheduled(cron 0 * * * * ?) public void releaseExpiredOrders() { ListTicketOrder expired orderMapper.selectExpired( OrderStatus.UNPAID.getCode(), LocalDateTime.now()); for (TicketOrder order : expired) { // 1. 取消订单 int updated orderMapper.cancelOrder(order.getId()); if (updated 0) { continue; // 已被其他线程处理 } // 2. 库存加回 stockMapper.restoreStock(order.getCategoryId(), order.getQuantity()); } }逻辑说明支付回调先验签再处理幂等判断放在最前面避免重复加库存或重复改状态。定时任务用cancelOrder的返回值做乐观锁只有真正把订单从待支付改成已取消的线程才去加库存防止并发重复加。参数说明cron表达式0 * * * * ?表示每分钟的第 0 秒执行。如果订单量很大可以改成每 30 秒一次但要注意任务执行时间不能超过间隔。selectExpired建议加LIMIT 100分批处理避免一次拉太多数据导致内存溢出。4. 避坑与排查购票系统上线前必须处理的五个问题4.1 库存超卖现象是卖出票数大于总库存现象压测时发现某个票档总库存 100但成功订单加起来有 105 张。原因扣库存的 SQL 没有加stock quantity条件或者用了先查后减但没加锁。并发下两个线程都查到库存为 1都认为够都执行了扣减。解决扣减 SQL 必须写成UPDATE ticket_stock SET stock stock - #{q} WHERE category_id #{id} AND stock #{q}用数据库的行锁和条件判断保证原子性。乐观锁的version字段也要带上双重保险。4.2 订单重复同一用户同一票档出现两条待支付订单现象用户反馈点了一次下单订单列表里出现两条一样的记录。原因防重令牌只在前端做了按钮置灰后端没做幂等。用户网络慢时重复提交或者直接调接口。解决后端用 RedisSETNX加锁或者给ticket_order表加user_id category_id status的唯一索引只对未支付状态生效需要额外处理。更稳妥的是生成一个全局唯一的request_id下单时带上服务端用request_id做幂等键。4.3 定时任务重复释放库存现象超时订单释放后库存加回了两次导致实际可售数量比预期多。原因定时任务在多实例部署时同时执行两个实例都查到同一批超时订单都执行了取消和加库存。解决取消订单的 SQL 加状态条件UPDATE ticket_order SET status 2 WHERE id #{id} AND status 0只有影响行数为 1 的实例才去加库存。或者用分布式锁保证同一时间只有一个实例执行任务。4.4 支付回调丢失导致订单一直待支付现象用户明明付了钱订单还是待支付15 分钟后被定时任务取消库存释放用户投诉。原因支付平台回调时网络抖动或者我们的服务正好在重启回调没收到。解决不能只依赖回调。加一个主动查询任务对超过 5 分钟还是待支付的订单主动调支付平台的查询接口确认状态。另外回调接口要做好日志记录方便排查。4.5 数据库连接池被打满现象开票瞬间接口大量超时日志里出现Connection is not available。原因下单事务里做了太多事情比如查用户信息、查演出详情、发短信导致事务持有连接时间过长。并发一上来连接池默认 HikariCP 10 个瞬间被占满。解决事务里只放必须原子性的操作查用户、发短信这些放到事务外。连接池大小根据数据库承载能力调整一般maximumPoolSize设为 CPU 核数 * 2 磁盘数但不要超过数据库的max_connections。压测时观察连接等待时间如果持续大于 0 就说明池子小了。5. 进阶技巧用本地缓存和限流把抢票体验拉回可用线前面讲的方案能保证数据正确但开票瞬间的体验还得再优化。我一般会加两个东西本地缓存和接口限流。本地缓存用 Caffeine把演出详情和票档信息缓存 10 秒。这些数据读多写少每次下单都查数据库没必要。注意缓存要设过期时间否则票档售罄了前端还显示有票。Configuration public class CacheConfig { Bean public CacheString, Object localCache() { return Caffeine.newBuilder() .expireAfterWrite(10, TimeUnit.SECONDS) // 写入10秒后过期 .maximumSize(1000) // 最多缓存1000条 .build(); } }限流用 Guava 的RateLimiter或 Sentinel对下单接口做单机限流。比如限制每秒 200 个请求超出的直接返回「当前排队人数过多」。这不是为了挡住用户而是为了保护数据库不被打挂。限流阈值根据压测结果定我一般从 100 QPS 开始压逐步往上加观察错误率和响应时间找到拐点。还有一个容易被忽略的点订单号生成不要用 UUID。UUID 太长作为数据库主键或唯一索引会影响插入性能而且无序会导致 B 树页分裂。用「yyyyMMddHHmmss 6 位随机数」就够了一天最多 86 亿种组合足够用。最后说一个我踩过的坑不要在下单接口里同步调用支付平台的统一下单接口。支付平台响应慢的时候你的线程全堵在那里。正确做法是下单成功后返回订单号前端再单独调支付接口。这样即使支付平台挂了下单功能还是可用的。这些经验都是一次次压测和线上问题换来的希望帮到你。本文还有配套的精品资源点击获取 Java高并发演唱会购票系统实战：库存扣减与订单幂等
简介本资源为基于Java开发的演唱会在线购票系统设计源码面向学习Java Web开发、课程设计或毕业设计的学生与开发者帮助理解在线购票业务从用户管理、票务查询到订单处理的核心实现。压缩包共37个文件约2.1MB包含13个Java源文件承载业务逻辑10个class编译产物6个XML配置文件用于数据源与环境参数设置另有SQL建表脚本、properties数据库连接配置、JAR依赖包及readme说明目录结构清晰便于按模块阅读与二次开发。目前已有91人学习下载。源码采用典型分层设计涵盖用户注册登录、演唱会信息浏览、选座支付与订单管理等模块并附带数据库脚本与依赖库可直接导入IDE运行调试适合作为在线购票系统设计与实现的完整参考范例帮助读者快速掌握Java项目结构、数据库操作与MVC分层思路。1. 演唱会在线购票系统为什么 Java 技术栈是这类高并发场景的稳妥选择抢票这件事做过的人都知道有多玄学。开票那一秒几十万人同时点同一个按钮库存只有几千张系统要么卡死要么超卖要么订单重复。演唱会在线购票系统的核心难点从来不是页面好不好看而是高并发下的库存一致性和订单幂等。这个标题指向的是一套用 Java 开发的在线购票系统源码适合有一定 Java 基础、想通过一个完整项目把 SSM 或 Spring Boot 用起来的开发者也适合课程设计或毕业设计阶段需要落地案例的同学。它要解决的问题很具体用户浏览演出场次、选座或选票档、下单锁库存、支付回调、超时释放。整条链路涉及数据库事务、缓存、消息队列和定时任务是一个能把 Java 后端主要知识点串起来的场景。相比简单的增删改查管理系统购票系统的技术密度更高面试时也更容易讲出深度。下面我会按实际落地顺序把技术选型、库表设计、核心代码和踩坑经验拆开讲清楚。2. 技术选型与工程结构从单体到可扩展的购票后端2.1 为什么选 Spring Boot MyBatis 而不是纯 Servlet常见做法是用 Spring Boot 2.x 搭配 MyBatis-Plus前端可以是 Thymeleaf 服务端渲染也可以前后端分离用 Vue。选 Spring Boot 的理由很直接内置 Tomcat、自动装配、starter 依赖管理能把精力放在业务逻辑而不是 XML 配置上。MyBatis 相比 JPA 更适合购票系统因为库存扣减这类操作需要手写 SQL 精确控制比如UPDATE ticket_stock SET stock stock - 1 WHERE stock 0这种带条件的原子更新用 ORM 自动生成反而不好控制。工程结构我一般会这样分concert-ticket/ ├── ticket-common/ # 通用工具、常量、统一返回体 ├── ticket-dao/ # 实体类、Mapper 接口、XML ├── ticket-service/ # 业务逻辑、事务控制 ├── ticket-web/ # Controller、拦截器、参数校验 └── ticket-job/ # 定时任务超时订单释放分层的好处是定时任务模块可以独立部署避免和 Web 请求抢资源。如果只是课程设计合并成一个模块也能跑但面试时讲出分层思路是加分项。2.2 数据库表设计五张核心表撑起整条链路购票系统的表不用多但每张都要设计到位。下面是我实际用过的核心表结构表名作用关键字段concert演出场次id, name, venue, show_time, statusticket_category票档id, concert_id, price, total_stockticket_stock库存独立表id, category_id, stock, versionticket_order订单id, order_no, user_id, category_id, quantity, status, expire_timepayment_record支付记录id, order_no, pay_time, amount, status把库存单独拆成ticket_stock表而不是放在ticket_category里是为了减少行锁竞争。票档信息读多写少库存写多读多分开后更新库存时不会锁住票档的查询。订单状态用枚举值管理0-待支付、1-已支付、2-已取消、3-已退款。expire_time字段记录订单超时时间默认下单后 15 分钟定时任务扫描这个字段来释放库存。2.3 库存扣减的两种方案与选择依据库存扣减是购票系统最容易翻车的地方。常见两种方案方案一数据库乐观锁。在ticket_stock表加version字段扣减时带上版本号UPDATE ticket_stock SET stock stock - #{quantity}, version version 1 WHERE category_id #{categoryId} AND stock #{quantity} AND version #{version}影响行数为 0 就说明被别人抢先改了重试或直接返回失败。优点是实现简单、不依赖额外组件缺点是并发高时重试次数多数据库压力大。方案二Redis 预扣减 数据库异步落库。开票前把库存加载到 Redis扣减用 Lua 脚本保证原子性成功后发消息到 MQ由消费者慢慢写数据库。优点是抗并发能力强缺点是引入 Redis 和 MQ复杂度和运维成本上升还要处理缓存和数据库的一致性。我的建议是课程设计或中小规模用方案一就够了把乐观锁和重试逻辑写清楚如果标题里强调高并发或者你想在面试里讲亮点再上方案二。不要为了炫技在数据量只有几百的时候硬上 Redis反而容易出数据不一致的问题。3. 核心功能落地下单、锁库存、支付回调的代码实现3.1 下单接口参数校验与防重复提交下单是整条链路的入口必须做好参数校验和幂等。用户可能因为网络卡顿连点两次也可能恶意刷单。我一般会在 Controller 层加一个基于 Redis 的防重令牌或者用userId categoryId做唯一索引兜底。PostMapping(/order/create) public Result createOrder(RequestBody Valid OrderCreateDTO dto, HttpServletRequest request) { Long userId getCurrentUserId(request); // 1. 参数校验数量必须大于0且不超过限购 if (dto.getQuantity() 0 || dto.getQuantity() 4) { return Result.fail(购票数量不合法); } // 2. 防重复提交同一用户同一票档5秒内只能提交一次 String lockKey order:lock: userId : dto.getCategoryId(); Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, 5, TimeUnit.SECONDS); if (Boolean.FALSE.equals(locked)) { return Result.fail(操作过于频繁请稍后再试); } try { // 3. 调用Service层创建订单 String orderNo orderService.createOrder(userId, dto); return Result.success(orderNo); } finally { // 注意这里不删锁让锁自然过期避免误删别人的锁 } }逻辑说明setIfAbsent对应 Redis 的SETNX设置 5 秒过期是防止死锁。参数校验用 JSR-303 注解在 DTO 上完成限购数量根据业务定演唱会一般每人限购 2 到 4 张。finally里不主动删锁是因为如果业务执行时间超过锁过期时间删锁可能删掉其他线程刚加的锁让锁自然过期更安全。参数方面quantity建议在 DTO 上用Min(1)和Max(4)双重限制categoryId必须校验是否存在且属于当前在售场次。3.2 库存扣减与订单创建的事务边界下单的核心是在一个事务里完成「扣库存 创建订单」。这两步必须同时成功或同时失败否则会出现扣了库存没订单或者有订单没扣库存。Transactional(rollbackFor Exception.class) public String createOrder(Long userId, OrderCreateDTO dto) { // 1. 查询库存带版本号 TicketStock stock stockMapper.selectByCategoryId(dto.getCategoryId()); if (stock null || stock.getStock() dto.getQuantity()) { throw new BizException(库存不足); } // 2. 乐观锁扣减库存 int affected stockMapper.deductStock( dto.getCategoryId(), dto.getQuantity(), stock.getVersion()); if (affected 0) { throw new BizException(当前购票人数过多请重试); } // 3. 创建订单 TicketOrder order new TicketOrder(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setCategoryId(dto.getCategoryId()); order.setQuantity(dto.getQuantity()); order.setStatus(OrderStatus.UNPAID.getCode()); order.setExpireTime(LocalDateTime.now().plusMinutes(15)); orderMapper.insert(order); return order.getOrderNo(); }逻辑说明Transactional的rollbackFor Exception.class确保任何异常都回滚包括受检异常。扣库存用乐观锁affected 0说明版本号对不上直接抛异常让事务回滚。订单号生成建议用「时间戳 用户ID后四位 随机数」不要用自增 ID 直接暴露。参数说明expire_time设为 15 分钟后这个值要和定时任务的扫描周期匹配。如果定时任务每分钟跑一次15 分钟意味着用户有 14 到 15 分钟的支付时间可以接受。如果设成 5 分钟用户刚打开支付页面就超时了体验很差。3.3 支付回调与超时订单释放支付回调是第三方支付平台通知我们支付结果必须做签名验证和幂等处理。超时释放则是定时任务扫描expire_time小于当前时间且状态为待支付的订单把库存加回去。// 支付回调 PostMapping(/pay/callback) public String payCallback(RequestBody PayCallbackDTO dto) { // 1. 验签防止伪造回调 if (!payService.verifySign(dto)) { return FAIL; } // 2. 幂等根据订单号查状态已支付直接返回成功 TicketOrder order orderMapper.selectByOrderNo(dto.getOrderNo()); if (order.getStatus() OrderStatus.PAID.getCode()) { return SUCCESS; } // 3. 更新订单状态和支付记录 orderService.markPaid(dto.getOrderNo(), dto.getPayTime()); return SUCCESS; }// 定时任务每分钟执行一次 Scheduled(cron 0 * * * * ?) public void releaseExpiredOrders() { ListTicketOrder expired orderMapper.selectExpired( OrderStatus.UNPAID.getCode(), LocalDateTime.now()); for (TicketOrder order : expired) { // 1. 取消订单 int updated orderMapper.cancelOrder(order.getId()); if (updated 0) { continue; // 已被其他线程处理 } // 2. 库存加回 stockMapper.restoreStock(order.getCategoryId(), order.getQuantity()); } }逻辑说明支付回调先验签再处理幂等判断放在最前面避免重复加库存或重复改状态。定时任务用cancelOrder的返回值做乐观锁只有真正把订单从待支付改成已取消的线程才去加库存防止并发重复加。参数说明cron表达式0 * * * * ?表示每分钟的第 0 秒执行。如果订单量很大可以改成每 30 秒一次但要注意任务执行时间不能超过间隔。selectExpired建议加LIMIT 100分批处理避免一次拉太多数据导致内存溢出。4. 避坑与排查购票系统上线前必须处理的五个问题4.1 库存超卖现象是卖出票数大于总库存现象压测时发现某个票档总库存 100但成功订单加起来有 105 张。原因扣库存的 SQL 没有加stock quantity条件或者用了先查后减但没加锁。并发下两个线程都查到库存为 1都认为够都执行了扣减。解决扣减 SQL 必须写成UPDATE ticket_stock SET stock stock - #{q} WHERE category_id #{id} AND stock #{q}用数据库的行锁和条件判断保证原子性。乐观锁的version字段也要带上双重保险。4.2 订单重复同一用户同一票档出现两条待支付订单现象用户反馈点了一次下单订单列表里出现两条一样的记录。原因防重令牌只在前端做了按钮置灰后端没做幂等。用户网络慢时重复提交或者直接调接口。解决后端用 RedisSETNX加锁或者给ticket_order表加user_id category_id status的唯一索引只对未支付状态生效需要额外处理。更稳妥的是生成一个全局唯一的request_id下单时带上服务端用request_id做幂等键。4.3 定时任务重复释放库存现象超时订单释放后库存加回了两次导致实际可售数量比预期多。原因定时任务在多实例部署时同时执行两个实例都查到同一批超时订单都执行了取消和加库存。解决取消订单的 SQL 加状态条件UPDATE ticket_order SET status 2 WHERE id #{id} AND status 0只有影响行数为 1 的实例才去加库存。或者用分布式锁保证同一时间只有一个实例执行任务。4.4 支付回调丢失导致订单一直待支付现象用户明明付了钱订单还是待支付15 分钟后被定时任务取消库存释放用户投诉。原因支付平台回调时网络抖动或者我们的服务正好在重启回调没收到。解决不能只依赖回调。加一个主动查询任务对超过 5 分钟还是待支付的订单主动调支付平台的查询接口确认状态。另外回调接口要做好日志记录方便排查。4.5 数据库连接池被打满现象开票瞬间接口大量超时日志里出现Connection is not available。原因下单事务里做了太多事情比如查用户信息、查演出详情、发短信导致事务持有连接时间过长。并发一上来连接池默认 HikariCP 10 个瞬间被占满。解决事务里只放必须原子性的操作查用户、发短信这些放到事务外。连接池大小根据数据库承载能力调整一般maximumPoolSize设为 CPU 核数 * 2 磁盘数但不要超过数据库的max_connections。压测时观察连接等待时间如果持续大于 0 就说明池子小了。5. 进阶技巧用本地缓存和限流把抢票体验拉回可用线前面讲的方案能保证数据正确但开票瞬间的体验还得再优化。我一般会加两个东西本地缓存和接口限流。本地缓存用 Caffeine把演出详情和票档信息缓存 10 秒。这些数据读多写少每次下单都查数据库没必要。注意缓存要设过期时间否则票档售罄了前端还显示有票。Configuration public class CacheConfig { Bean public CacheString, Object localCache() { return Caffeine.newBuilder() .expireAfterWrite(10, TimeUnit.SECONDS) // 写入10秒后过期 .maximumSize(1000) // 最多缓存1000条 .build(); } }限流用 Guava 的RateLimiter或 Sentinel对下单接口做单机限流。比如限制每秒 200 个请求超出的直接返回「当前排队人数过多」。这不是为了挡住用户而是为了保护数据库不被打挂。限流阈值根据压测结果定我一般从 100 QPS 开始压逐步往上加观察错误率和响应时间找到拐点。还有一个容易被忽略的点订单号生成不要用 UUID。UUID 太长作为数据库主键或唯一索引会影响插入性能而且无序会导致 B 树页分裂。用「yyyyMMddHHmmss 6 位随机数」就够了一天最多 86 亿种组合足够用。最后说一个我踩过的坑不要在下单接口里同步调用支付平台的统一下单接口。支付平台响应慢的时候你的线程全堵在那里。正确做法是下单成功后返回订单号前端再单独调支付接口。这样即使支付平台挂了下单功能还是可用的。这些经验都是一次次压测和线上问题换来的希望帮到你。本文还有配套的精品资源点击获取