滑雪场的售票系统和普通电商比起来有个特别折磨人的点库存不是简单的总数而是每天限量——雪场容量有限节假日必须限流票种又分日场、夜场、季卡、教学套餐价格体系还随淡旺季浮动。我去年给一家中型雪场做过一套基于Spring Boot的售票系统从需求梳理到部署上线差不多用了两个月中间踩了不少坑今天把整个设计思路和核心实现完整盘一遍希望能给正在做同类项目的朋友一些参考。1. 滑雪票务的业务特殊性为什么不能照搬电商秒杀方案先说一个反直觉的结论滑雪售票系统最核心的技术难点不是高并发秒杀而是时间维度上的库存管理和履约闭环。雪场单日接待量有上限缆车运力、雪道容量、租赁装备数量都决定了每天能卖多少票所以库存模型天然是票种日期的二维结构这和电商里一个SKU对应一个总库存的模型有本质区别。1.1 票种维度和价格策略拆解滑雪场的票务体系通常比想象中复杂我梳理了某雪场实际运营时的票种分类大致如下票种大类典型子类型定价逻辑库存策略入场票日场票、夜场票、全日票按时间段淡旺季浮动按日期限量季卡单人季卡、家庭季卡固定价预售为主总量控制不分日期教学产品私教课、团体课按教练时段定价按教练时间段分配租赁套餐雪具租赁、储物柜附加服务随门票组合关联门票库存这里有个容易被忽略的需求夜场票和日场票在跨天时段比如夜场从18:00到22:00跨了营业日期的场次归属问题。很多系统在早期设计时把日期当成简单的售卖日期结果核销时发现夜场票的使用日期和售卖日期不是同一天导致对账混乱。正确的做法是给票种增加一个有效使用日期字段和下单日期解耦。1.2 库存模型的三个核心约束我在设计阶段和雪场运营负责人反复确认后总结出库存模型必须满足的三个约束这也是后续所有技术决策的出发点日期容量约束每个票种每天有独立的最大售卖量比如日场票每天限售800张夜场限售500张。这个数字由雪场承载力决定不是拍脑袋定的。超卖保护约束用户下单后到支付完成前库存需要被预占超过支付时限要自动释放。这里不能简单用数据库行锁否则高峰期会锁等待严重。核销闭环约束票售出后必须能验证真伪且一张票只能核销一次。线上的订单状态和线下的入园记录必须打通。这三个约束决定了系统的技术选型数据库需要支持精准的库存扣减Redis要承担预占和热点数据缓存订单状态机要覆盖从创建到核销的完整生命周期。2. 技术选型与整体架构单体应用的分层实践很多同学一上来就想着微服务、消息队列、分布式事务实际上对于单雪场规模的售票系统来说Spring Boot单体应用加良好分层完全够用而且维护成本低得多。我最终的选型是Spring Boot 2.7 MyBatis-Plus MySQL 8.0 Redis 6.xJDK用17。2.1 为什么不用微服务滑雪场售票系统高峰期也就节假日那几天QPS撑死几百真正要命的是业务逻辑的复杂性而不是并发量。如果拆成订单服务、库存服务、支付服务三个微服务光是分布式事务就够喝一壶的——库存扣减和订单创建需要强一致用Seata之类的方案引入额外的运维负担对一个小型项目来说是得不偿失的。单体应用配合合理的模块划分效果完全一样。我的项目结构是这样的ski-ticketing/ ├── controller/ # 接口层只做参数校验和结果封装 ├── service/ # 业务逻辑层事务边界在这里 │ ├── order/ # 订单相关 │ ├── inventory/ # 库存相关 │ ├── payment/ # 支付回调 │ └── ticket/ # 出票、核销 ├── mapper/ # 数据访问层 ├── entity/ # 数据库实体 ├── dto/ # 请求响应对象 ├── config/ # Redis、线程池、拦截器配置 └── common/ # 统一返回、异常处理、工具类这个分层的核心原则是事务必须在service层控制controller层不允许直接操作数据库。后面排查库存扣减问题时会发现如果事务边界乱放会出现各种诡异的并发问题。2.2 Redis在系统里的三个角色Redis在这个系统里不只是缓存它承担了三个职责这也是库存不超卖的关键库存预占计数器用Redis的DECR和INCR命令实现下单前的原子扣减扣减成功的订单才允许落库。这里用的是Redis的原子性而不是分布式锁。分布式锁在真正操作数据库扣减库存时用Redisson的tryLock保证同一天同一票种的并发扣减是串行的。锁的粒度是票种日期不是全局锁否则性能会退化得很厉害。热点缓存票种列表、价格表、库存余量这些读多写少的数据缓存到Redis减少数据库压力。特别是首页的余量展示如果每次都查数据库高峰期数据库连接会被打满。这里有个关键的时序问题Redis预占和数据库扣减不是同时发生的。用户下单时先Redis预占然后创建订单状态为待支付最后再异步扣减数据库库存。为什么这么设计因为从下单到支付之间有很长的时间窗口数据库库存如果提前扣了用户超时未支付还得做反向补偿很容易出现数据库和Redis数据不一致的问题。3. 数据库设计库存日历和订单状态机的建模数据库是整个系统的地基建表阶段多花一天思考后面能少加一个星期的班。我重点讲三张核心表的设计思路。3.1 库存日历表以天为粒度的库存核心表库存表不能只存总数必须按日期展开。我的设计如下CREATE TABLE ticket_inventory ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, ticket_type_id BIGINT NOT NULL COMMENT 票种ID, sale_date DATE NOT NULL COMMENT 售卖日期使用日期, total_stock INT NOT NULL DEFAULT 0 COMMENT 总库存, sold_stock INT NOT NULL DEFAULT 0 COMMENT 已售库存, locked_stock INT NOT NULL DEFAULT 0 COMMENT 锁定库存待支付, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_ticket_date (ticket_type_id, sale_date), KEY idx_sale_date (sale_date) ) ENGINEInnoDB COMMENT 票种库存日历表;这张表的核心是三个库存字段total_stock是当天该票种的总量sold_stock是已支付出票的数量locked_stock是预占但未支付的数量。剩余可卖库存 total_stock - sold_stock - locked_stock。为什么单独拆一个locked_stock字段因为对账时需要知道哪些票被锁了但没付款这直接关系到超卖风险的评估。如果只要sold_stock一个字段释放锁定时就要做减法逻辑容易混乱。3.2 订单表和状态机的完整生命周期订单表是交易的核心载体我用的是扩展状态机设计CREATE TABLE ticket_order ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 订单号全局唯一, user_id BIGINT NOT NULL COMMENT 用户ID, ticket_type_id BIGINT NOT NULL, sale_date DATE NOT NULL COMMENT 使用日期, quantity INT NOT NULL DEFAULT 1 COMMENT 购买数量, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0待支付 1已支付 2已出票 3已核销 4已取消 5已退款, pay_expire_time DATETIME NOT NULL COMMENT 支付截止时间, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_status_expire (status, pay_expire_time) ) ENGINEInnoDB COMMENT 订单表;订单状态流转路径为待支付 → 已支付 → 已出票 → 已核销待支付超时后走已取消。这里我建议用一个TinyInt类型存状态码而不是字符串数据库索引效率更高。状态流转的代码必须放在一个独立的方法里用UPDATE ... WHERE status ?做条件更新这是后面实现幂等的基础。3.3 核销记录表一张票只能进一次雪场核销是滑雪系统特有的闭环动作我单独设计了一张核销记录表CREATE TABLE ticket_verification ( id BIGINT NOT NULL AUTO_INCREMENT, ticket_code VARCHAR(64) NOT NULL COMMENT 电子票唯一码, order_id BIGINT NOT NULL, verify_time DATETIME NOT NULL COMMENT 核销时间, verify_channel TINYINT NOT NULL COMMENT 核销渠道1闸机 2人工 3小程序, operator_id BIGINT DEFAULT NULL COMMENT 操作员ID, PRIMARY KEY (id), UNIQUE KEY uk_ticket_code (ticket_code) ) ENGINEInnoDB COMMENT 核销记录表;uk_ticket_code唯一索引是核心防重复核销手段——同一个人拿着同一个票码在闸机上刷两次第二次插入会因为唯一索引冲突而失败。这种约束用应用层判断是挡不住并发请求的只有数据库约束最可靠。4. 核心交易链路实现库存扣减就是一场防超卖的攻防战整个系统技术含量最高的部分就是下单接口的库存扣减逻辑。我前前后后重构了三版这里把最终版本的完整思路和代码贴出来。4.1 下单接口的整体流程下单接口不是直接扣库存而是走一个预占 落单 异步确认的流程Transactional(rollbackFor Exception.class) public OrderVO createOrder(Long userId, Long ticketTypeId, LocalDate saleDate, Integer quantity) { // 1. 前置校验票种是否存在、日期是否在售卖范围内 TicketType ticketType ticketTypeService.getById(ticketTypeId); Assert.notNull(ticketType, 票种不存在); Assert.isTrue(!saleDate.isBefore(LocalDate.now()), 不能购买过去的日期); // 2. Redis预占库存原子扣减防止超卖的第一道防线 String stockKey buildStockKey(ticketTypeId, saleDate); Long remaining redisTemplate.opsForValue().decrement(stockKey, quantity); if (remaining null || remaining 0) { // 扣减失败需要回补 redisTemplate.opsForValue().increment(stockKey, quantity); throw new BizException(当日库存不足); } try { // 3. 生成订单号落库订单数据 String orderNo generateOrderNo(); TicketOrder order new TicketOrder(); order.setOrderNo(orderNo); order.setUserId(userId); // ... 设置票种、日期、金额等字段 order.setStatus(0); order.setPayExpireTime(LocalDateTime.now().plusMinutes(15)); orderMapper.insert(order); // 4. 异步扣减数据库库存乐观锁 inventoryService.deductStock(ticketTypeId, saleDate, quantity); return buildOrderVO(order); } catch (Exception e) { // 5. 回补Redis库存保证最终一致性 redisTemplate.opsForValue().increment(stockKey, quantity); throw e; } }这段代码的关键在Redis预占和数据库扣减的配合。Redis的DECR是原子操作不会出现两个线程同时扣减同一份库存的问题这是第一道防线。数据库的UPDATE带乐观锁这是第二道防线。两道防线都通过才算是真正锁定了库存。4.2 乐观锁扣减数据库库存的具体实现数据库层的库存扣减不能写成先查再改必须用一条SQL完成条件更新public boolean deductStock(Long ticketTypeId, LocalDate saleDate, Integer quantity) { // 只有当剩余可卖库存大于等于购买数量时才允许扣减 int rows inventoryMapper.deductStock(ticketTypeId, saleDate, quantity); return rows 0; }对应的Mapper SQLupdate iddeductStock UPDATE ticket_inventory SET sold_stock sold_stock #{quantity}, version version 1 WHERE ticket_type_id #{ticketTypeId} AND sale_date #{saleDate} AND (total_stock - sold_stock - locked_stock) #{quantity} AND version #{version} /update这个SQL的巧妙之处在于WHERE条件里直接计算剩余库存只有满足条件才更新否则影响行数为0。配合version字段做乐观锁即使两个事务同时执行也只有一个能成功更新。这里我必须强调一个实际踩过的坑如果version是每次查询时带上、更新时校验的那么在高并发场景下两个线程可能拿到相同的version然后一个成功、一个失败失败的请求直接报库存不足给用户。但实际上库存是够的只是并发冲突。后来我的处理方式是在WHERE里不加version条件只依赖剩余库存数量这个业务条件来判断。数据库的行锁会保证同一行数据的更新是串行的后到的请求会阻塞在前一个事务提交后然后重新评估条件。4.3 支付回调的幂等处理支付回调是另一个容易出问题的环节。第三方支付平台为了保证通知送达会多次回调同一个订单如果处理逻辑不幂等订单状态会被覆盖甚至重复出票。我的解决方式是状态更新用条件更新只有当前状态待支付时才允许改成已支付Transactional(rollbackFor Exception.class) public void handlePayCallback(String orderNo, String transactionId) { // 幂等关键只有待支付状态才能流转到已支付 int rows orderMapper.updateStatusByCondition(orderNo, 0, 1, transactionId); if (rows 0) { // 已经处理过回调或订单状态不允许流转 log.warn(支付回调重复处理或状态异常orderNo{}, orderNo); return; } // 支付成功后的后续操作扣减locked_stock、生成电子票 ticketService.issueTicket(orderNo); }这里updateStatusByCondition的SQL是核心UPDATE ticket_order SET status 1, pay_transaction_id #{transactionId}, pay_time NOW() WHERE order_no #{orderNo} AND status 0多条并发回调执行这条SQL时数据库行锁会保证只有一个请求能成功更新其他的影响行数为0直接返回。这样无论回调多少次出票逻辑只执行一次。5. 超时未支付与库存回补定时任务的补偿机制用户下单后如果15分钟内不支付订单要自动取消锁定的库存要释放。这个场景如果用定时任务全局扫描效率太低而且会有几分钟的延迟。我采用的是延迟队列 定时任务补偿的双保险方案。5.1 基于Redis延迟队列的准实时释放下单成功后把订单号丢进一个带过期时间的Redis键里利用Redis的键过期事件来触发取消逻辑。不过Redis的过期事件有延迟而且默认不保证可靠性所以只作为辅助手段。我的做法是先把订单号写入一个ZSetscore设为过期时间戳然后用一个后台线程每隔10秒扫描一次public void setupOrderExpireListener() { ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); scheduler.scheduleWithFixedDelay(() - { long now System.currentTimeMillis(); // 取出所有已过期的订单号 SetString expiredOrders redisTemplate.opsForZSet() .rangeByScore(ORDER_EXPIRE_QUEUE, 0, now); for (String orderNo : expiredOrders) { cancelExpiredOrder(orderNo); // 处理完从ZSet移除 redisTemplate.opsForZSet().remove(ORDER_EXPIRE_QUEUE, orderNo); } }, 0, 10, TimeUnit.SECONDS); }这里线程池的线程数不需要多一个就够了因为取消操作的频率不会很高。真正要注意的是cancelExpiredOrder的方法必须加分布式锁防止和支付回调同时操作同一个订单。5.2 取消订单时的库存回补逻辑取消订单时Redis预占的库存和数据库的locked_stock都要释放顺序不能反Transactional(rollbackFor Exception.class) public void cancelExpiredOrder(String orderNo) { // 用分布式锁锁住订单防止和支付回调并发冲突 RLock lock redissonClient.getLock(order:lock: orderNo); if (!lock.tryLock(0, 3, TimeUnit.SECONDS)) { return; // 没拿到锁说明有其他线程在处理跳过 } try { TicketOrder order orderMapper.selectByOrderNo(orderNo); if (order null || order.getStatus() ! 0) { return; // 订单不存在或已支付不能取消 } // 1. 先把订单置为已取消 int rows orderMapper.updateStatusByCondition(orderNo, 0, 4); if (rows 0) { return; } // 2. 释放数据库锁定库存 inventoryMapper.releaseLockedStock(order.getTicketTypeId(), order.getSaleDate(), order.getQuantity()); // 3. 回补Redis预占库存 redisTemplate.opsForValue().increment(buildStockKey(order.getTicketTypeId(), order.getSaleDate()), order.getQuantity()); } finally { lock.unlock(); } }这个流程里最关键的细节是先更新订单状态再释放库存。如果反过来先释放库存再取消订单极端情况下会出现用户支付成功了但因为订单被取消而无法出票还占用着已经释放的库存对账时彻底崩溃。6. 线上踩过的坑库存超卖、脏读和日期时区问题最后的章节必须分享我在联调和上线阶段遇到的真实问题很多是文档里查不到的经验。6.1 压测发现超卖问题出在事务没有提交就读取系统上线前用JMeter做了并发压测结果发现加了Redis预占和数据库乐观锁之后依然出现了超卖。排查了很久最后定位到问题不在扣减逻辑而在库存余量查询接口。余量查询的逻辑是先查Redis预占数量再查数据库已售数量然后用总量相减。但在并发场景下一个订单的数据库扣减还没提交事务另一个线程就能读到扣减前的数据导致余量查询结果虚高用户看到有票下单时却报库存不足。这个问题最终通过调整事务隔离级别和查询顺序解决余量查询直接查数据库的total_stock - sold_stock - locked_stock不再依赖Redis的预占数量。Redis的预占数只在下单接口内部使用不作为对外展示的数据源。6.2 夜场票的跨天日期问题夜场票的营业时间是18:00到次日凌晨1点如果按自然日设计库存表会出现12月31日的夜场票和1月1日凌晨的场次归属不清的问题。我的解决方案是引入一个营业日概念每天晚上20点之前夜场票的sale_date填的是当天晚上20点之后购买的夜场票sale_date填的是次日。这样虽然用户看到的日期是12月31日夜场数据库中实际存的可能是1月1日夜场但完全不影响核销因为夜场票的有效期是购买当晚。这里唯一的坑是报表统计时如果按sale_date分组统计会把12月31日晚上买的夜场票统计到1月1日的数据里。需要在报表SQL里做一层映射把20点以后购买的票归属到购买当天。6.3 核销并发请求的串行化闸机扫码核销的并发量虽然不大但存在同一张票在手机端和闸机端同时核销的可能性。我通过一个分布式锁加数据库唯一索引的双保险解决public void verifyTicket(String ticketCode) { RLock lock redissonClient.getLock(verify:lock: ticketCode); lock.lock(); try { // 先查核销记录已核销的直接拒绝 TicketVerification existing verificationMapper.selectByTicketCode(ticketCode); if (existing ! null) { throw new BizException(该票已核销请勿重复使用); } // 插入核销记录依赖唯一索引兜底 TicketVerification verification new TicketVerification(); verification.setTicketCode(ticketCode); verification.setVerifyTime(LocalDateTime.now()); verificationMapper.insert(verification); // 同步更新订单状态为已核销 orderMapper.updateStatusByCondition(orderNo, 2, 3); } finally { lock.unlock(); } }这个方案里分布式锁保证了业务层面的串行唯一索引保证了极端情况下的数据完整性。实际生产环境里分布式锁可能因为Redis超时等原因失效这时候唯一索引就是最后一道防线这也是为什么我一直强调数据库约束比应用层判断更可靠。7. 总结之外这套设计的扩展可能整个系统的核心已经讲完了最后分享几个我觉得可以继续优化的方向。如果雪场后续要做会员体系可以在订单表上增加member_id和points_amount字段在下单接口里加积分抵扣逻辑对现有架构完全无损。如果要对接小程序扫码入园只需要在核销接口上加一个开放API层用AppId和Secret做签名认证就行。如果要接大屏实时数据看板可以从数据库的binlog里同步销售数据到统计库现有的事务逻辑不用动。我个人最深的体会是业务系统的设计不在于用了多牛的技术框架而在于把业务约束理解透然后用最简单可靠的方式去满足这些约束。Spring Boot本身不复杂复杂的是库存不能超卖订单不能重复出票支付回调必须幂等这些看似朴素却暗藏玄机的业务规则。希望这篇文章能帮你少走一些弯路特别是库存扣减那段真的是拿线上事故换来的经验。