简介面向需要研究12306购票流程或进行二次开发的Java开发者这份基于Java的12306转移仓库设计与源码实现方案提供了完整的工程化参考。方案以Java为主干辅以Python脚本和Shell工具覆盖登录、余票查询、自动提交订单、验证码识别、配置管理等典型场景可用于优化12306转移仓库的管理与自动化操作流程。资源包共86个文件含60个Python脚本、5个PNG图像、4个文本文件、3个Markdown文档、2个HTML5页面、2个JPEG图像以及Dockerfile、docker-compose.yml、Shell脚本、Git/Docker忽略文件等压缩包大小59.05MB。文件类型兼顾源码、界面截图、环境配置与说明文档便于按模块查阅。源码中内置了自定义异常体系、网络请求封装及配置管理模块并附带代理与CDN列表可用于自动化购票流程的技术验证。目前已有240人学习适合具备一定Java和Python基础的开发者参考其多语言混合架构与容器化部署方式用于实际项目改造或技术验证。1. 12306场景里的“转移仓库”是什么它管的是票额从一个状态到另一个状态的原子流转几乎每个写Java的人都被人问过12306的余票是怎么在不超卖的情况下扣下去的真正要动手做的时候会发现最难的不是写一个抢票脚本去刷接口而是服务端怎么把一张票从“可售”变成“已占用”再从“已占用”变成“已售出”或者“已释放”。这个负责票额状态流转的模块就是标题里的“转移仓库”。转移仓库要处理的具体问题包括用户买一张跨越多个车站的长途票需要同时扣减沿途每个区段的库存用户买联程票时需要对多趟车做库存转移支付超时、退票时还要按原路径把库存加回来。如果不做独立的转移仓库这些操作散落在订单、支付、退改签多个模块里超卖和库存对不上只是时间问题。这套方案适合谁呢想用Java把高并发场景做完整的后端开发者、准备Java面试需要真实亮点的人以及课程设计选了票务系统、不想只做CRUD的人。下面我按一套可落地的Spring Boot工程来讲从表结构到核心代码再到我踩过的坑。2. 数据模型与表结构用五张表把票额转移状态机落地2.1 先把库存粒度定下来为什么按“车次物理区段日期座别”拆如果把一趟车看成一个整体库存用一个字段存余票数那么所有买同一趟车的请求都会去更新同一行并发冲突会非常严重。更重要的是长途票和短途票会互相踩踏。比如G101从北京西出发经停济南西、南京南到上海虹桥全车1000个座位。如果只存一个“北京西-上海虹桥”的余票数等于1000那一个买北京西到济南西的乘客扣掉1剩999可这999并不能直接卖给济南西到上海虹桥的人因为部分座位可能已经被买北京西到上海虹桥的人提前占了。要解决这个问题必须引入“物理区段”的概念。物理区段是相邻两个站之间的一段轨道区间。G101包含北京西-济南西、济南西-南京南、南京南-上海虹桥三个区段。任何一张票无论怎么买最终都落在物理区段上买北京西到上海虹桥三个区段各占1个座位买北京西到济南西只占第一个区段。所以库存表的最小粒度应该是“车次日期区段座别”而不是“车次日期”。这样设计以后“剩余座位”的含义变了它不再是整列车的空座数而是某个物理区段上还能再卖出去的通过能力。真实场景中北京西到上海虹桥只剩1张、北京西到济南西还有10张是完全可能的因为济南西到南京南区段可能已经被大量短途票占用。理解这一点转移仓库的表结构才有意义。2.2 五张核心表从列车停站到转移事件我把转移仓库的表拆成五张列车经停站序表、物理区段库存表、订单区间占用表、转移事件表、本地消息任务表。下面是一份可以直接执行的MySQL DDL省略了部分次要字段。-- 列车经停站序表保存每趟车每个站的顺序和到发时间 CREATE TABLE train_station_seq ( id BIGINT PRIMARY KEY AUTO_INCREMENT, train_no VARCHAR(16) NOT NULL COMMENT 车次号, station_code VARCHAR(8) NOT NULL COMMENT 站码如BJP, station_name VARCHAR(32) NOT NULL, seq_no INT NOT NULL COMMENT 从1开始的经停顺序, arrive_time TIME NULL, depart_time TIME NULL, UNIQUE KEY uk_train_station (train_no, station_code), KEY idx_train_seq (train_no, seq_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 物理区段库存表 CREATE TABLE segment_stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, train_no VARCHAR(16) NOT NULL, depart_date DATE NOT NULL, segment_code VARCHAR(16) NOT NULL COMMENT 相邻站站码拼接如BJP-JNP, seat_type VARCHAR(8) NOT NULL COMMENT 二等座/一等座/硬卧…, total_count INT NOT NULL DEFAULT 0 COMMENT 初始票额总数, remaining INT NOT NULL DEFAULT 0 COMMENT 当前可售数量, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0停用, UNIQUE KEY uk_train_date_seg_seat (train_no, depart_date, segment_code, seat_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单区间占用表 CREATE TABLE order_route_occupy ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, train_no VARCHAR(16) NOT NULL, depart_date DATE NOT NULL, start_seq INT NOT NULL COMMENT 上车站在列车时刻表中的顺序号, end_seq INT NOT NULL COMMENT 下车站顺序号, seat_type VARCHAR(8) NOT NULL, ticket_count INT NOT NULL DEFAULT 1, status TINYINT NOT NULL DEFAULT 0 COMMENT 0锁定中 1已支付 2已释放 3已退票, expire_time DATETIME NOT NULL, version INT NOT NULL DEFAULT 0, KEY idx_order_no (order_no), KEY idx_expire (status, expire_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 转移事件表 CREATE TABLE transfer_event ( id BIGINT PRIMARY KEY AUTO_INCREMENT, event_no VARCHAR(64) NOT NULL COMMENT 幂等键业务类型订单号区段ID, biz_type VARCHAR(16) NOT NULL COMMENT LOCK/RELEASE/RETURN/REFUND, stock_id BIGINT NOT NULL, delta INT NOT NULL COMMENT 负数表示扣减正数表示回补, occupy_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0已记账 1已对账, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_event_no (event_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 本地消息任务表用于跨服务最终一致 CREATE TABLE transfer_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_no VARCHAR(64) NOT NULL, task_type VARCHAR(16) NOT NULL COMMENT CONFIRM_OCCUPY/CANCEL_OCCUPY/RELEASE, occupy_id BIGINT NOT NULL, retry_count INT NOT NULL DEFAULT 0, next_retry_time DATETIME NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待处理 1成功 2死信, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_task_no (task_no), KEY idx_next_retry (status, next_retry_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;segment_stock 是整个转移仓库的核心。total_count 在初始化时写入对账时就靠它做恒等校验。remaining 是当前可售数量所有扣减都必须带“remaining 本次扣减量”的条件这是防超卖的第一道闸。version 是乐观锁字段用来在并发冲突时做审计而不是用来做主要的CAS判断因为条件更新本身已经足够原子。transfer_event 是审计的灵魂每一笔扣减或回补都写一条带唯一 event_no 的记录这样后面无论遇到重复请求还是定时任务重试都能用唯一索引挡住。订单区间占用表记录的是“某个订单占用了某趟车从 start_seq 到 end_seq 的票”它不直接存区段而是存起止站在列车时刻表里的顺序号。这样查询这个订单影响了哪些物理区段时拿着 start_seq 和 end_seq 去 train_station_seq 反查即可或者更直接的通过 transfer_event 里的 occupy_id 反查涉及的所有 stock_id。两个方向都行我一般用后者因为对账时它不需要再关联车站表。2.3 初始化与状态机让一张列车时刻表变成可扣减的区间票池有了表结构下一步要把基础的时刻表数据转成区段库存。我在初始化服务里写一个方法按相邻站生成区段记录。这个方法在每天凌晨或者新开列车时执行重复执行不会破坏已有库存。Service public class StockInitService { Resource private TrainStationSeqMapper trainStationSeqMapper; Resource private SegmentStockMapper segmentStockMapper; /** * 为某趟车在指定日期初始化相邻区段库存 * * param trainNo 车次号如 G101 * param departDate 乘车日期 * param seatCount 该车该座别的定员数 * param seatType 座别如二等座 */ public void initStock(String trainNo, LocalDate departDate, int seatCount, String seatType) { ListTrainStationSeq stations trainStationSeqMapper.selectByTrainNo(trainNo); for (int i 0; i stations.size() - 1; i) { String fromCode stations.get(i).getStationCode(); String toCode stations.get(i 1).getStationCode(); String segmentCode fromCode - toCode; // insert ignore 保证重复初始化不会覆盖已调整过的库存 segmentStockMapper.insertIgnore(trainNo, departDate, segmentCode, seatType, seatCount, seatCount); } } }这里的关键参数是 seatCount它必须是这趟车这款座别的物理定员数比如一组复兴号二等座有576个。所有相邻区段初始都放相同数量卖票时按实际覆盖的区段扣减。insertIgnore 配合表上的唯一索引保证同一天同一区段同一座别不会被重复插入。如果你用 MyBatis PlusinsertIgnore 可以用INSERT IGNORE语句实现或者先查再插但后者在高并发初始化时有重复风险不如前者省心。这五张表定义好之后库存的状态流转基本清晰了segment_stock.remaining 从初始化后的 total_count 开始通过 LOCK 事件扣减通过 RELEASE/RETURN/REFUND 事件回补。order_route_occupy 在锁定、支付、释放、退票之间流转。转移仓库要做的就是把这两个状态机绑在一起保证任何时刻所有已占用票的总数与 segment_stock 的扣减总量一致。3. Java核心实现乐观锁扣减、Redis锁与事务边界3.1 一条UPDATE完成库存扣减先锁行再减还是条件更新最常见的错误写法是先 SELECT 查询剩余量在 Java 里判断是否够用再 UPDATE 扣减。这个流程在并发下一查一改之间另一个线程可能已经改了库存最终导致超卖。正确做法是把判断放到 UPDATE 的 WHERE 条件里让数据库在行锁内完成“判断扣减”的原子操作。Mapper public interface SegmentStockMapper { Update(UPDATE segment_stock SET remaining remaining - #{delta}, version version 1 WHERE id #{stockId} AND remaining #{delta} AND status 1) int deduct(Param(stockId) Long stockId, Param(delta) int delta); Update(UPDATE segment_stock SET remaining remaining #{delta}, version version 1 WHERE id #{stockId} AND status 1) int release(Param(stockId) Long stockId, Param(delta) int delta); }deduct 的返回值就是数据库受影响行数。返回 0 表示两种可能库存不足或者区段已停用。Service 层拿到 0 后抛出明确异常让上层事务整体回滚。release 是回补操作为什么也要加 condition因为如果同一个 stock_id 被误调用两次库存就会多出来。release 本身不判断 remaining 上限但需要配合事件表的幂等键和占用表的状态保证不会重复回补。delta 参数这里指“本单需要的票数”通常一次订单买 1 到 3 张不建议把这个值放太大否则一条 UPDATE 锁住的行长时间占着会影响其他区段的并发。3.2 跨多个区段的联程锁定排序加锁避免死锁一张北京西到上海虹桥的车票覆盖三个物理区段需要同时锁三行。如果循环调用 deduct第一段成功、第二段失败事务回滚没问题但在高并发下两个订单可能分别先锁不同区段形成互相等待的死锁。解决方式是在一个事务内先 SELECT ... FOR UPDATE 锁住所有需要的区段行并且强制按 segment_code 排序。Transactional(rollbackFor Exception.class) public void lockRoute(OrderCreateRequest req) { // 先按起止站顺序查出覆盖的所有物理区段加行锁 ListSegmentStock stocks segmentStockMapper.selectForUpdate( req.getTrainNo(), req.getDepartDate(), req.getStartSeq(), req.getEndSeq()); // 所有线程按同一个顺序加锁大大降低死锁概率 stocks.sort(Comparator.comparing(SegmentStock::getSegmentCode)); for (SegmentStock stock : stocks) { if (stock.getRemaining() req.getTicketCount()) { throw new StockNotEnoughException(stock.getSegmentCode()); } int affected segmentStockMapper.deduct(stock.getId(), req.getTicketCount()); if (affected ! 1) { throw new ConcurrentModifyException(stock.getSegmentCode()); } } // 写占用记录状态为“锁定中”15分钟后未支付会被定时任务释放 OrderRouteOccupy occupy new OrderRouteOccupy(); occupy.setOrderNo(req.getOrderNo()); occupy.setTrainNo(req.getTrainNo()); occupy.setDepartDate(req.getDepartDate()); occupy.setStartSeq(req.getStartSeq()); occupy.setEndSeq(req.getEndSeq()); occupy.setSeatType(req.getSeatType()); occupy.setTicketCount(req.getTicketCount()); occupy.setStatus(OrderOccupyStatus.LOCKED.getCode()); occupy.setExpireTime(LocalDateTime.now().plusMinutes(15)); orderOccupyMapper.insert(occupy); // 每个区段的扣减都写一条转移事件方便对账和退改 for (SegmentStock stock : stocks) { transferEventMapper.insert( TransferEvent.lockEvent(req.getOrderNo(), stock.getId(), -req.getTicketCount(), occupy.getId())); } }selectForUpdate 的 SQL 需要按 start_seq、end_seq 从 station_seq 反查出区段编码也可以用 where 条件直接划范围具体看你的索引设计。这里有个容易被忽视的参数req.getStartSeq() 和 req.getEndSeq() 是用户选择的上车站和下站站在这趟车经停顺序中的位置而不是站点名称。用顺序号的好处是计算覆盖区段时只需要一个范围条件seq_no startSeq AND seq_no endSeq对应物理区段就是segment_stock.segment_code 在中间区间列表内。实际项目里我会先查一次 station_seq 把区段编码列表拼出来再执行selectForUpdate避免在 SQL 里写复杂子查询。为什么先取出来在内存里 sort 一遍再 update因为 InnoDB 的行锁虽然天然有队列但两个事务获取锁的顺序不同时仍会出现死锁并触发回滚。排序后所有事务都按 segment_code 从小到大加锁死锁概率几乎为零。这也是面试官最爱追问的“你怎么解决高并发下的死锁”的实操答案。3.3 跨车次转移的最终一致性本地消息表兜底如果订单里有两趟车比如 G101 从北京西到济南西再换 G158 从济南西到上海虹桥这时候两个车次的库存可能分属不同库甚至不同服务。单库事务包不住了网上常说的分布式事务太重票务场景更常用的是“本地消息表 定时重试”。核心思路是先在自己的库里完成能锁的库存并写入一条待确认任务然后由后台任务把确认动作推到下游。Scheduled(fixedDelay 5000) Transactional public void processPendingTasks() { ListTransferTask tasks transferTaskMapper.selectPending(LocalDateTime.now(), 100); for (TransferTask task : tasks) { try { // 调用下游服务确认占用下游必须支持幂等 boolean ok downstreamService.confirmOccupy(task.getOccupyId()); if (ok) { transferTaskMapper.markSuccess(task.getId()); } else { transferTaskMapper.retryLater(task.getId(), task.getRetryCount() 1); } } catch (Exception e) { // 记录失败原因进入重试队列 transferTaskMapper.retryLater(task.getId(), task.getRetryCount() 1); } } }这里最重要的参数是 selectPending 的时间阈值和拉取数量。时间阈值通常设为当前时间之前的 1 分钟避免刚写入的任务立即被扫描到留给事务提交足够的缓冲拉取数量 100 是保守值防止一次任务太多导致数据库连接池被占满。retryLater 要更新 next_retry_time一般按 1 分钟、5 分钟、15 分钟的递增间隔超过 5 次就把 status 置为 2死信转人工处理。confirmOccupy 必须用 occupy_id 做幂等下游重复收到同一任务不能重复扣库存。这个方案是最终一致不是强一致但在 12306 这种场景里用户看到下单结果前后端允许有几百毫秒的账期后台任务只要在秒级内把两趟车都锁定就没问题。3.4 释放与回退幂等键让退票不重复加库存释放是锁定的逆操作但不只是简单的反向扣减。支付超时、用户取消、退票成功都会触发释放同一个订单可能同时被多个线程触发释放比如用户点了取消同时支付回调超时任务也扫描到这个订单。如果不做幂等库存会被回补两次。Transactional(rollbackFor Exception.class) public void releaseOccupy(Long occupyId, String reason) { // 1. 锁住占用行防止两个线程同时进入 OrderRouteOccupy occupy orderOccupyMapper.selectByIdForUpdate(occupyId); if (occupy null || occupy.getStatus() ! OrderOccupyStatus.LOCKED.getCode()) { return; // 已释放或已支付直接返回 } // 2. 先改占用状态成功才继续回补库存 int updated orderOccupyMapper.updateStatus( occupyId, OrderOccupyStatus.RELEASED.getCode(), OrderOccupyStatus.LOCKED.getCode(), occupy.getVersion()); if (updated ! 1) { return; // 状态被其他线程改掉了放弃 } // 3. 根据事件表查出这个订单影响的所有区段 ListLong stockIds transferEventMapper.selectStockIdsByOccupyId(occupyId); for (Long stockId : stockIds) { segmentStockMapper.release(stockId, occupy.getTicketCount()); } // 4. 记一条幂等的释放事件 transferEventMapper.insert( TransferEvent.releaseEvent(occupyId, reason)); }顺序很重要先更新占用状态再回补库存。如果反过来回补成功了但状态没改成已释放下一次释放又会重复回补。updateStatus 的 where 条件里带上了“status 等于锁定中”和“version 等于旧值”保证只有真正处于锁定中的订单能被释放一次。最后的 transferEvent 用 event_no 做唯一键即使 releaseOccupy 被重新调用第二次进来在步骤 2 就会因为状态不匹配而退出不会走到回补。4. 避坑转移仓库最容易翻车的五个现场4.1 现象释放回补时把整趟车所有区段库存都加了我见过最直接的翻车是把回补 SQL 写成UPDATE segment_stock SET remaining remaining #{delta} WHERE train_no #{trainNo} AND depart_date #{departDate}少了 segment_code 条件。退一张票全车所有区段每段都被加回一张库存虚高后面卖出超出物理座位数的票用户上车才发现没座位。原因就是把“物理区段”和“车次”的粒度搞混了。解决回补前必须根据订单的 transfer_event 查出精确的 stock_id 列表逐条回补或者 UPDATE 时用stock_id IN (...)绝不能用车次日期这种粗粒度条件。4.2 现象联程锁了一半库存另一半失败用户买 G101 接 G158 的中转票主服务先锁了 G101 的三段再去锁 G158 时下游超时接口返回下单失败。前端提示失败但 G101 的库存已经扣了而且因为跨服务事务已经提交回滚不了。这就是没有用消息表兜底的后果。解决把“锁 G101”和“锁 G158”拆成两个本地事务第一步锁完只写一条 pending 的 transfer_task后台任务再去锁 G158如果 G158 一直失败重试超过阈值后自动把 G101 释放。用户看到的是“稍后出票”而不是“成功了可实际没票”。4.3 现象Redis锁过期重复订单同时进入扣减有些团队会在扣减前加 Redis 分布式锁防止同一个用户疯狂点击产生多个一模一样的订单。这个锁如果只定一个固定过期时间处理时间长一点就会过期第二个请求又进来了。我没有把 Redis 锁当成唯一的防空手段而是在 lockRoute 里给它配一个唯一业务键 order_no并在 order_route_occupy 表上加 uk_order_no 唯一索引。这样即使 Redis 锁过期第二个请求插入占用记录时也会因唯一键冲突失败。Redis 锁可以缩短用户重复点击的等待时间但数据库唯一键才是最后的底气。4.4 现象库存被扣成负数居然没有报错把扣减 SQL 写成SET remaining remaining - #{delta}然后 Java 里先查 remaining 再判断够不够。并发低的时候看着没问题并发一高两个线程查到同一个 remaining都认为够一起扣库存就变成 -1 了。解决就是第 3.1 节的条件更新WHERE remaining #{delta}。这条 SQL 在数据库层面保证了不够就不扣。如果你用的 MySQL 8.0还可以在表上加CHECK (remaining 0)但我一般不加因为条件更新已经够了check 约束在分库分表场景反而容易碍事。4.5 现象压测一上去就死锁事务耗时飙到秒级事务里先锁了 A 区段再去查别的表拿数据另外一个事务先锁了 B 区段再查同一张表两边互相等最终死锁。MySQL 会选一个事务回滚但代价是连接被占住、监控报警一堆。解决事务里禁止做远程调用禁止大量查询所有需要的区段在事务开头一次性锁完并且统一排序。还有一个小技巧把 InnoDB 的锁等待超时调小比如innodb_lock_wait_timeout 3让死锁快速暴露而不是拖垮连接池。压测时如果日志里大量Deadlock found先检查锁顺序而不是盲目加索引。5. 验证与进阶用测试用例和压测证明这套转移仓库能扛住抢票5.1 单元测试跑通一次锁定、占用、释放的完整转移我习惯用一套不依赖外部中间件的测试来证明核心逻辑没跑偏。利用 Spring Boot 的 Transactional 注解让每个测试方法跑完自动回滚不至于污染本地库。SpringBootTest Transactional class StockTransferServiceTest { Autowired private StockInitService stockInitService; Autowired private StockTransferService stockTransferService; Autowired private SegmentStockMapper segmentStockMapper; Test void testLockAndRelease() { // 初始化一趟三区段列车每个区段10张 stockInitService.initStock(G101, LocalDate.of(2026, 5, 1), 10, 二等座); // 购买北京到上海覆盖3个区段买2张 OrderCreateRequest req new OrderCreateRequest(); req.setOrderNo(TEST20260501001); req.setTrainNo(G101); req.setDepartDate(LocalDate.of(2026, 5, 1)); req.setStartSeq(1); req.setEndSeq(4); req.setSeatType(二等座); req.setTicketCount(2); stockTransferService.lockRoute(req); // 每个区段剩余应该是8 ListSegmentStock stocks segmentStockMapper.selectByTrainAndDate( G101, LocalDate.of(2026, 5, 1)); for (SegmentStock stock : stocks) { assertEquals(8, stock.getRemaining()); } // 释放这个订单库存回到10 Long occupyId orderOccupyMapper.selectIdByOrderNo(TEST20260501001); stockTransferService.releaseOccupy(occupyId, PAY_TIMEOUT); for (SegmentStock stock : stocks) { assertEquals(10, stock.getRemaining()); } } }这个测试覆盖了最核心的“Lock 后剩余减少、Release 后恢复”。注意初始化的 seatCount 是 10所以每个区段最多只能卖 10 张长票。如果你把一个跨越 3 个区段的订单买 2 张三段的 remaining 都应该同时变成 8。任何一个区段没扣成功事务会回滚测试就会失败这就达到了目的。5.2 压测参数设计200线程抢同一段余票单元测试只能验证逻辑不能验证并发边界。我用 JMeter 做一轮简单压测重点看两个指标是否超卖、是否死锁。参数设计如下参数推荐值说明线程数200模拟同一时间集中抢票Ramp-up1 秒让请求尽量同时到达循环次数100制造足够多的竞争订单号UUID 动态生成避免幂等干扰监听器聚合报告 断言断言接口返回成功压测前先初始化库存G101 三区段各放 1000 张然后把“北京西到上海虹桥”设置成热门请求200 个线程同时去抢。压测结束后跑对账 SQL如果剩余量加占用量不等于 1000就说明有超卖。如果日志中出现死锁优先看锁顺序是否加了排序。这里有个容易翻车的点连接池大小不要调得太大默认 50 就够了否则数据库连接等待反而把平均响应时间拉高。5.3 每日对账库存总量守恒是最后的底牌逻辑再怎么严密还是要有独立的对账机制兜底。我每天晚上跑一遍对账脚本核心 SQL 是利用 transfer_event 做净变化量核对SELECT s.id, s.total_count, s.remaining, COALESCE(SUM(e.delta), 0) AS net_changed FROM segment_stock s LEFT JOIN transfer_event e ON e.stock_id s.id GROUP BY s.id, s.total_count, s.remaining HAVING s.remaining - COALESCE(SUM(e.delta), 0) ! s.total_count;这条 SQL 的逻辑是初始化时 remaining 等于 total_count之后每次 LOCK 写负 deltaRELEASE 写正 delta所以理论上 remaining 减去累计 delta 恒等于 total_count。一旦不等于说明中间有账没记平要么是某次扣减没有写事件要么是释放多执行了一次。跑出来的结果直接推到钉钉告警人工去查对应 stock_id 的 transfer_event 明细通常很快能定位到是哪个订单导致的。这套转移仓库做完后我最大的感触是票务系统的难点不在框架用了多新而在每个状态转换有没有留下可审计、可回滚的痕迹。以前我也迷信过玄学调优后来发现条件更新、幂等键、对账脚本这三个基本功才是保命的。无论是应付 Java 面试还是实际项目把“一条 UPDATE 防超卖”和“一个 event_no 防重复”讲透比背一堆八股文有用得多。希望帮到你。本文还有配套的精品资源点击获取