拓冰网站定制 
简介这套基于Java的12306转移仓库设计与源码实现方案面向铁路票务系统及数据管理方向的Java开发者与运维人员针对12306高并发场景下的仓库转移流程进行优化提供从业务建模到容器化部署的完整参考。资源共86个文件压缩包约59.05MB其中60个Python脚本构成核心工具链覆盖自动登录、余票查询、排队下单、验证码识别等环节同时包含Dockerfile、docker-compose.yml等容器化配置以及Markdown文档、PNG/JPEG界面图、模型文件等便于理解整体架构与运行方式。目前已有240人学习下载适合希望借鉴真实项目源码、快速掌握多语言协作与容器部署的进阶学习者。源码不仅给出设计思路还提供可运行的实现代码及配置说明可帮助读者缩短二次开发周期体会业务封装、异常处理与自动化测试等工程化实践。1. 基于Java的12306转移仓库先搞懂这个标题到底在解决什么问题如果你在12306上买过跨站票大概率遇到过这样一个现象从A站到C站没票但买A到B、B到C两段反而有票。这背后不是简单的“分段计价”而是铁路售票系统把票额按照区间预分配到了不同“票仓”每个仓管一段区间。但区间票额是死的乘客需求是活的所以系统必须在运行过程中把票额从一个仓转移到另一个仓——这个过程就是“转移仓库”。标题里的“基于Java”指的是用Java技术栈把这件事从业务逻辑到源码落地。这篇文章要解决的不是去复刻整个12306而是把你带到“余票分区 动态调配”这个具体场景里讲清楚转移仓库的数据结构怎么设计、并发扣减怎么做原子操作、源码怎么组织以及那些一上线就翻车的边界条件。适合谁看正在做票务、库存、预约类系统的Java工程师以及准备Java面试时想拿高并发案例当谈资的候选人。它不挑中间件核心思路是Redis 数据库 消息队列你手头有这些就能复现。2. 把“仓库转移”拆成数据模型先立住理论再写代码2.1 三层结构分区库存、公共池、转移流水我接手过的几个库存类系统第一版都是把库存放在一张大表里一个update扣完。单机没问题一旦拆成多区域、多仓这种模型立刻卡死。12306的余票之所以难做是因为“一张票”不是全局唯一它在每个区间都有自己的库存计数。所以转移仓库的第一步是把库存拆成三层来看。第一层是分区库存表存的是某个区间的可售数量。比如“北京西—郑州东”这个区间对应一个warehouse_id字段包括total_count、sold_count、available_count。第二层是公共池它不属于任何具体区间是为了应对突发需求而预留的共享库存转移操作的本质就是在分区库存和公共池之间搬移数量。第三层是转移流水表记录每一次转移的时间、数量、源仓库、目标仓库、操作人、状态位。这三层展开到表结构核心就三张表。分区库存表是唯一允许并发扣减的地方公共池只有调度任务能碰流水表只做插入不做更新。在设计上我建议把这三张表放在同一个数据库实例里因为它们的事务关系非常强强行分库只会让“扣减并写流水”这个操作变得极其难保证原子性。CREATE TABLE warehouse_stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, warehouse_code VARCHAR(32) NOT NULL COMMENT 仓库编码如 BJB-ZZD, total_count INT NOT NULL DEFAULT 0, sold_count INT NOT NULL DEFAULT 0, available_count INT NOT NULL DEFAULT 0, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_warehouse_code (warehouse_code) ); CREATE TABLE stock_transfer_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, transfer_no VARCHAR(64) NOT NULL, source_warehouse VARCHAR(32) NOT NULL, target_warehouse VARCHAR(32) NOT NULL, transfer_count INT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待执行 1-成功 2-失败, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP );这个建表方案里有几个值得注意的参数。warehouse_code做成唯一索引是为了防止并发创建重复仓库带来的脏数据。version字段不是给业务查询看的是给扣减时的乐观锁用的它在UPDATE语句里充当CAS的比对条件。available_count永远等于total_count减去sold_count但你不需要在SQL里冗余计算只要在扣减的时候保证总票数不减就行。2.2 约束一分区库存扣减不能出现负值转移仓库最容易犯的错误是“先转移再扣减”的顺序颠倒。比如郑州到武汉的仓不够了你把北京仓的票转移过去然后才扣。这个顺序在分布式环境下有一个致命的漏洞转移操作还没提交用户侧扣减已经发生了两边一合并就出现超卖。我在设计时会定死一条铁律任何扣减都必须发生在转移之后且扣减必须带上版本号。意思是业务侧先调用转移服务拿到一个转移成功的回执再执行扣减扣减的SQL必须写成“UPDATE warehouse_stock SET available_count available_count - #{count}, version version 1 WHERE warehouse_code #{code} AND available_count #{count} AND version #{version}”。affected rows为0就说明版本被别的事务改过了要么重试要么拒绝服务。这里有个Java后端常见的坑很多团队会把version检查放在Service层用select先查再update。这不是原子操作两个线程查到同一个version先后update第二个人的where条件已经失效了。正确做法是把version判断塞进SQL的where子句让数据库来做CAS。2.3 约束二转移是异步的查询允许短期不一致回到那个“买不到直达票”的场景你可能会想为什么用户查余票时系统不能实时去把其他仓的票调过来答案是查询链路过长。一次余票查询可能涉及上千个区间节点的库存汇总如果每次查询都触发一次跨仓转移数据库的写压力会直接拖垮读性能。所以转移仓库在工程上必须是异步的。常见做法是查询接口只读当前分区的available_count不做任何汇总和转移动作后台启动一个定时任务每隔几秒扫描那些即将售罄或长期低效的分区计算出需要转移的票额生成转移任务丢到消息队列里异步执行。用户看到的余票数可能是几秒前的快照但拿到票之后系统有能力在几秒内补齐库存这个短期不一致是业务可以接受的。这个决策直接决定了你后面源码的模块划分。查询模块不依赖转移模块转移模块不阻塞主流程两者之间通过数据库流水表解耦。热词里那些“12306抢票脚本”“余票监控”之所以不靠谱就是因为它们根本碰不到真正的库存系统只能靠轮询刷新页面。3. 核心链路落地RedisLua保证原子扣减异步任务衔接数据库3.1 为什么不直接用数据库乐观锁扛所有并发数据库乐观锁能保证不超卖但它扛不住高频扣减。12306高峰期每秒的扣减请求是万级甚至十万级的一次UPDATE要占用连接、要锁行、要写binlog数据库连接池很快耗尽。所以生产环境通常会用Redis前置一层把热仓库存加载到内存里扣减在Redis里完成再把结果异步刷回数据库。Redis扣减的核心是Lua脚本它保证了“检查余票、扣减、写流水”这三个动作在Redis单线程模型里是原子的。选Lua而不是用Java代码里get然后set是因为Redis的事务本身不支持回滚Pipeline请求中间一旦失败前面成功的命令不会撤销只有Lua脚本能在一个原子单元里完成全部逻辑。3.2 库存扣减的Lua脚本与Java调用参数-- KEYS[1]: 仓库库存Key例如 stock:warehouse:BJB-ZZD -- KEYS[2]: 流水Key存储转移或扣减记录 -- ARGV[1]: 本次扣减数量 -- ARGV[2]: 业务单号 -- 返回值: 1-成功 0-失败 local available redis.call(HGET, KEYS[1], available) if not available or tonumber(available) tonumber(ARGV[1]) then return 0 end redis.call(HINCRBY, KEYS[1], available, -tonumber(ARGV[1])) redis.call(HINCRBY, KEYS[1], sold, tonumber(ARGV[1])) redis.call(RPUSH, KEYS[2], ARGV[2] .. : .. ARGV[1]) return 1这段Lua脚本里有三个参数必须说清楚。KEYS[1]用的是Hash结构而不是String因为一个仓库至少有三个字段要维护——available、sold、version拆成三个String做不了一个原子的HINCRBY。KEYS[2]是流水Key你可以在Java调用时把它设置成当天的日期比如stock:transfer:20250323这样方便后续异步任务按天扫描重放。ARGV[1]是扣减数量注意它必须是整数且大于0函数入口要做参数校验否则负数扣减会在HINCRBY里直接变成增加库存。Java端调用这个脚本用Spring Data Redis的DefaultRedisScript最省事。脚本只需要在启动时初始化一次不要每次请求都重新加载脚本内容否则Redis会反复执行SCRIPT LOAD白白消耗网络和内存。Component public class StockDeductService { private static final String DEDUCT_SCRIPT local available redis.call(HGET, KEYS[1], available) if not available or tonumber(available) tonumber(ARGV[1]) then return 0 end redis.call(HINCRBY, KEYS[1], available, -tonumber(ARGV[1])) redis.call(HINCRBY, KEYS[1], sold, tonumber(ARGV[1])) redis.call(RPUSH, KEYS[2], ARGV[2] .. : .. ARGV[1]) return 1; private final DefaultRedisScriptLong deductScript; public StockDeductService(RedisTemplateString, String redisTemplate) { this.deductScript new DefaultRedisScript(); this.deductScript.setScriptText(DEDUCT_SCRIPT); this.deductScript.setResultType(Long.class); } public boolean deduct(String warehouseCode, int count, String bizNo) { Long result redisTemplate.execute( deductScript, Arrays.asList(stock:warehouse: warehouseCode, stock:flow: LocalDate.now()), String.valueOf(count), bizNo ); return Long.valueOf(1L).equals(result); } }这段Java代码踩过几个坑你照着写能少走弯路。execute方法的第三个参数必须是数组或List不能传单个字符串否则RedisCallback解析参数时会报类型错误。bizNo必须包含业务语义我习惯拼成“orderId_warehouseCode_count”这种格式方便在查流水时一眼看出是哪个订单扣了哪个仓。另外注意RedisTemplate的序列化器如果你把key的序列化器配成了Jackson存储到Redis里的key会带上包名类名前缀Lua里HGET的时候RedisTemplate帮你序列化但Lua不会两边一对不上就永远返回nil。解决办法是key和field都用StringRedisSerializer。3.3 转移任务如何从Redis落回MySQLRedis里的扣减成功了MySQL里的库存在哪里更新这里有两条链路可以走。更稳的是异步双写Redis扣减成功只是“临时占用”任务会带着扣减明细写入MQ消费端拿到消息再对数据库执行乐观锁更新。更简单的是定时对账每天一个定时任务扫描Redis流水把当天所有扣减记录批量合并成一次UPDATE操作回写MySQL再做一次Redis和MySQL的双向校验。我在实战中会选择前者因为它的延迟低数据库能在秒级追上Redis的状态。但MQ消费必须实现幂等消费端在更新数据库之前先查一遍流水表同一个bizNo如果已经存在就跳过。这一步不做的后果是消息重投会带来重复扣减用户明明买了一张票数据库里却扣了两张的库存。4. 源码实现方案从包结构到核心类手写一个可运行的转移引擎4.1 Maven工程与包结构为什么按领域而不是按三层架构拆很多Java项目的源码拆包是按controller、service、mapper三层来拆的这个结构写CRUD够用但写转移仓库这种偏业务的系统会很痛苦。三层拆法的问题是转移相关的调度逻辑、Redis逻辑、数据库逻辑散落在三个包下新来的同事看半天也不知道一个完整的转移流程串在哪里。我建议按领域拆。常见的做法是顶层分成warehouse、transfer、schedule、common四个包。warehouse包管仓库的增删改查和库存扣减transfer包管转移任务的生成、执行、补偿schedule包管定时扫描和任务调度common包只放工具类、统一返回体、异常定义。这样每个包下的类能独立自测转移逻辑不会污染到仓库查询。一个仓库转移任务的完整包结构如下新增业务时照着这个骨架往里填类就行src/main/java/com/train12306/ ├── common/ │ ├── exception/BizException.java │ └── result/Result.java ├── warehouse/ │ ├── controller/WarehouseController.java │ ├── service/StockDeductService.java │ ├── service/StockQueryService.java │ └── repository/WarehouseStockMapper.java ├── transfer/ │ ├── controller/TransferController.java │ ├── service/TransferService.java │ ├── service/TransferExecuteService.java │ ├── mq/TransferConsumer.java │ └── repository/StockTransferLogMapper.java └── schedule/ ├── StockScanner.java └── TransferTaskScheduler.java这里要说明的是controller的存在不是为了暴露HTTP接口而是为了本地调试和运维手动触发。生产环境的转移任务通常由定时任务发起但留一个手动触发的入口能让运维在紧急调配时不用改代码。很多系统上线后才发现没有手动入口只能临时写SQL这是很不专业的做法。4.2 TransferService转移动作的入口与参数说明转移的核心动作是“把A仓的库存搬给B仓”它要处理的不只是一条UPDATE而是涉及两个仓库的原子性变化。完整的转移动作是扣减Source仓的available增加Target仓的available同时写入一条transfer_log。这三个操作在数据库层面要用事务包住任何一个失败都整体回滚。Service public class TransferService { private final WarehouseStockMapper stockMapper; private final StockTransferLogMapper logMapper; private final TransactionTemplate transactionTemplate; public TransferService(WarehouseStockMapper stockMapper, StockTransferLogMapper logMapper, TransactionTemplate transactionTemplate) { this.stockMapper stockMapper; this.logMapper logMapper; this.transactionTemplate transactionTemplate; } public String transfer(String sourceWarehouse, String targetWarehouse, int count) { if (count 0) { throw new BizException(转移数量必须大于0); } String transferNo TF System.currentTimeMillis() RandomStringUtils.randomNumeric(4); transactionTemplate.executeWithoutResult(status - { int sourceRows stockMapper.deductAvailable(sourceWarehouse, count, VersionHolder.get(sourceWarehouse)); if (sourceRows 0) { status.setRollbackOnly(); throw new BizException(源仓库库存不足或版本冲突); } int targetRows stockMapper.increaseAvailable(targetWarehouse, count); if (targetRows 0) { status.setRollbackOnly(); throw new BizException(目标仓库不存在); } StockTransferLog log new StockTransferLog(); log.setTransferNo(transferNo); log.setSourceWarehouse(sourceWarehouse); log.setTargetWarehouse(targetWarehouse); log.setTransferCount(count); log.setStatus((byte) 1); logMapper.insert(log); }); return transferNo; } }这段代码里最需要注意的是TransactionTemplate而不是Transactional。Spring的Transactional默认只在抛出RuntimeException时回滚而transfer()方法内部调用了两个Mapper如果第二个Mapper失败抛的是受检异常事务是不会回滚的。TransactionTemplate把事务边界显式化setRollbackOnly 抛出BizException能确保两个仓库的变更一定同时提交或同时回滚。还有一个容易被忽略的参数是VersionHolder它是一个ThreadLocal负责在本次请求上下文中保存源仓库的最新版本号。为什么不用Mapper里查出来的旧版本因为deductAvailable的where条件需要比对最新版本而如果先在Service里select再传给Mapperselect和update之间可能有别的线程插进来修改版本号。正确做法是在Mapper的update语句里直接select版本号或者用VersionHolder在事务开启前读一次。4.3 定时扫描与MQ消费转移指令如何形成闭环只有transfer方法还不能叫“方案”因为没有人告诉它“什么时候该转移、转移多少”。这一步由调度模块接替它干两件事扫描库存水位生成转移指令。扫描周期不宜太短5秒一次足够太频繁会加重数据库查询压力转移阈值的判定也很关键我常用两个条件一个是剩余可用数低于总票数的10%且未来2小时有售票高峰另一个是当前分区客流预测明显高于另一分区。扫描器拿到数据后不直接调transfer而是丢给MQ。这么做的好处是削峰——高峰期可能同时有几百个分区需要转移如果全部同步执行数据库连接直接被占满正常售票反而被拖垮。MQ积压几分钟不影响业务因为转移本身是一个“预调整”不是“实时必须完成”的动作。消费端拉取转移指令后再去调TransferService。如果转移失败不要无限重试设置最大重试次数为3超过3次把状态置为2并写入失败原因。失败的任务会由第二天的对账任务统一处理做“反向转移”把多转的库存搬回去。这个闭环是整个方案里最容易被忽略的环节很多团队只写了转移成功的路径失败了对账完全空白最后账目越差越多。5. 实战避坑从并发扣减到数据补偿的六个翻车现场5.1 现象Redis显示库存够但数据库扣减却超卖这个是压测时最容易撞见的问题。Redis里available还剩5张一次并发来了8个请求Lua脚本拦住了3个5个放行数据库收到5条消息却扣了7行的库存。根因是消费端幂等没做。MQ在极端场景下会重复投递同一条消息消费端如果直接执行UPDATE而不先查流水表同一条扣减消息被消费两次数据库就多扣一次。解决方法是消费端先查StockTransferLogtransfer_no存在就直接ack不再执行SQL。5.2 现象扣减成功了但用户收到“订单已关闭”的提示用户端显示扣款成功票却没出。追踪日志发现Redis的扣减发生在RDB持久化之前进程重启后库存恢复到了扣减前的状态但MySQL已经扣了。根因是Redis的持久化策略和异步双写之间的时间差。解决方法是把Redis当“缓存”而不是“数据源”每次扣减后立即发MQ以数据库为准。Redis重启丢了数据就用数据库里的可用数重新加载而不是等到对账任务第二天才修。5.3 现象转移任务积压源仓库库存被搬空高峰期转移指令积压了几千条消费端慢慢消费结果发现某个热门分区的票被全部转移到另一个仓本区反而没票卖。根因是转移脚本只看库存阈值没看实时客流。解决方法是给每个仓库加一个transfer_in_progress标记位同一时间只允许一条转移任务在读这个仓。同时把“转移”和“扣减”分开上锁扣减走Redis原子操作不受影响转移在数据库层面加了行锁两个操作就不会互相踩。5.4 现象数据库连接池被扣减SQL打爆负责库存扣减的Mapper只有一个高峰期每秒上万个扣减请求全部落在它身上。数据库连接池默认配置只有10个其他查询全部阻塞。根因是没给扣减接口单独配置独立线程池。解决方法是把库存扣减的线程池和普通查询解耦扣减线程池核心线程数设为2的倍数根据CPU核数定队列容量控制在1000以内满了直接返回“繁忙”而不是继续堆积。后端的MQ还有一层缓冲用户在界面看到繁忙总比超时好。5.5 现象压测通过一上线余额就错这个最头疼UAT环境压测完全正常生产跑2小时一算账发现总票数对不上。根因是生产环境的MySQL事务隔离级别是READ_COMMITTED而UAT是REPEATABLE_READ。两种隔离级别下两个并发事务对同一个version的可见性不同导致乐观锁在UAT里拦截了冲突生产里却没拦住。解决方法是把SQL里的version比对改成“availabe_count扣减数”这个条件再配合Redis的Lua预扣不要只依赖乐观锁。生产环境上线前必须把隔离级别核对一遍REPEATABLE_READ下验证通过不代表READ_COMMITTED也通过。5.6 现象转移成功但流水缺失对账时无从查起事务里写了transfer_log但事务提交前应用宕机导致库存变了但流水没落库。根因是事务回滚条件不满足logMapper的异常被吞了。解决方法是把流水写入放在最前面——先写流水占位状态置为“执行中”再改库存。成功后更新状态为成功失败则保留“执行中”让对账任务掃描出来重放。这个顺序牺牲了一点性能但换来了账目可追溯我觉得完全值得。6. 进阶验证把源码推到Git仓库后用对账脚本证明系统没算错源码写完只代表“能跑”不代表“没算错”。验证整个转移仓库的正确性核心是一份独立的对账脚本。这份脚本不允许依赖业务代码里的任何方法只查数据库和Redis用SQL的聚合函数算一遍总数。常用的验证思路是这样的统计所有warehouse_stock表的available_count之和减去所有transfer_log里成功状态的数量之和结果必须等于0。如果不等于0说明有转移没有写流水或者流水存在但库存没变更。这个校验意义很大因为它在逻辑上把两个独立的数据源绑在了一起任何一边有遗漏都会暴露。# 通过MySQL命令行执行生产环境建议放到跳板机 mysql -h127.0.0.1 -utrain -p123456 train_ticket -e SELECT SUM(available_count) AS total_available FROM warehouse_stock; mysql -h127.0.0.1 -utrain -p123456 train_ticket -e SELECT SUM(transfer_count) AS total_transfer FROM stock_transfer_log WHERE status 1; redis-cli --scan --pattern stock:warehouse:* | xargs -L 1 redis-cli HGETALL跑完之后你会发现一个有意思的问题Redis里每个仓库的available字段累加出来和数据库里SUM的结果对不上。原因不用慌因为Redis是实时扣减后的数数据库是异步消费后的数中间必然存在一个时间差。对账看的是趋势而不是瞬时的相等。我一般会给这个对账脚本加一个允许误差范围参数比如误差在20张以内视为正常超过则触发告警并锁定相关仓库禁止转移。验证通过后记得把项目推到你自己的代码仓库用命令行演示一次完整的提交和分支管理流程。我习惯在Git仓库里维护一个release分支源码推上去之前先跑一遍JUnit集成测试确认Lua脚本和Java代码能协同工作。推送命令很简单但里边的坑在于.gitignore一定要把target/和*.log排除掉否则会把编译产物和日志文件一并推到仓库既不专业也浪费空间。Maven配置多镜像仓库可以见第4章包结构这里就不展开了。6.2 压测转移引擎控制变量才能看出真实瓶颈最后说一个我的惯性做法每次压测我只改变一个变量。比如先固定100个并发用户关闭Redis只测MySQL乐观锁的扣减吞吐再开启Redis比对两者数据差。你把Redis去掉测一遍能清楚看到数据库能扛到多少加上Redis再测一遍看看纯Redis的Lua脚本能到每秒多少笔。这两个数字之间的差就是Redis带来的收益。如果实际收益不到30%说明你的Lua脚本写得有问题或者序列化配置不对别急着加机器先回头看代码。压测结束后把结果汇总成一个表记录压测场景、并发数、TPS、错误率、数据库连接池最大活跃数。这张表不只是给领导看更是给自己下次调优留参照。我吃过一次亏上次优化完Redis脚本自测单机TPS从2万涨到5万结果一接入真实流量反而超时。复盘才发现压测机连的是本机Redis而生产Redis是主从架构写入要等从节点同步延迟高了一个数量级。后来我每次压测都用生产相同规格的Redis实例再也没翻过车。希望这些从数据模型、源码组织到压测验证的经验能帮你在做余票、库存、预约类系统时少走一点弯路。至少下次面试官问起“12306的票仓是怎么调度的”你能不慌不忙把这套方案讲清楚。本文还有配套的精品资源点击获取 基于Java的12306余票转移仓库设计与高并发实战
简介这套基于Java的12306转移仓库设计与源码实现方案面向铁路票务系统及数据管理方向的Java开发者与运维人员针对12306高并发场景下的仓库转移流程进行优化提供从业务建模到容器化部署的完整参考。资源共86个文件压缩包约59.05MB其中60个Python脚本构成核心工具链覆盖自动登录、余票查询、排队下单、验证码识别等环节同时包含Dockerfile、docker-compose.yml等容器化配置以及Markdown文档、PNG/JPEG界面图、模型文件等便于理解整体架构与运行方式。目前已有240人学习下载适合希望借鉴真实项目源码、快速掌握多语言协作与容器部署的进阶学习者。源码不仅给出设计思路还提供可运行的实现代码及配置说明可帮助读者缩短二次开发周期体会业务封装、异常处理与自动化测试等工程化实践。1. 基于Java的12306转移仓库先搞懂这个标题到底在解决什么问题如果你在12306上买过跨站票大概率遇到过这样一个现象从A站到C站没票但买A到B、B到C两段反而有票。这背后不是简单的“分段计价”而是铁路售票系统把票额按照区间预分配到了不同“票仓”每个仓管一段区间。但区间票额是死的乘客需求是活的所以系统必须在运行过程中把票额从一个仓转移到另一个仓——这个过程就是“转移仓库”。标题里的“基于Java”指的是用Java技术栈把这件事从业务逻辑到源码落地。这篇文章要解决的不是去复刻整个12306而是把你带到“余票分区 动态调配”这个具体场景里讲清楚转移仓库的数据结构怎么设计、并发扣减怎么做原子操作、源码怎么组织以及那些一上线就翻车的边界条件。适合谁看正在做票务、库存、预约类系统的Java工程师以及准备Java面试时想拿高并发案例当谈资的候选人。它不挑中间件核心思路是Redis 数据库 消息队列你手头有这些就能复现。2. 把“仓库转移”拆成数据模型先立住理论再写代码2.1 三层结构分区库存、公共池、转移流水我接手过的几个库存类系统第一版都是把库存放在一张大表里一个update扣完。单机没问题一旦拆成多区域、多仓这种模型立刻卡死。12306的余票之所以难做是因为“一张票”不是全局唯一它在每个区间都有自己的库存计数。所以转移仓库的第一步是把库存拆成三层来看。第一层是分区库存表存的是某个区间的可售数量。比如“北京西—郑州东”这个区间对应一个warehouse_id字段包括total_count、sold_count、available_count。第二层是公共池它不属于任何具体区间是为了应对突发需求而预留的共享库存转移操作的本质就是在分区库存和公共池之间搬移数量。第三层是转移流水表记录每一次转移的时间、数量、源仓库、目标仓库、操作人、状态位。这三层展开到表结构核心就三张表。分区库存表是唯一允许并发扣减的地方公共池只有调度任务能碰流水表只做插入不做更新。在设计上我建议把这三张表放在同一个数据库实例里因为它们的事务关系非常强强行分库只会让“扣减并写流水”这个操作变得极其难保证原子性。CREATE TABLE warehouse_stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, warehouse_code VARCHAR(32) NOT NULL COMMENT 仓库编码如 BJB-ZZD, total_count INT NOT NULL DEFAULT 0, sold_count INT NOT NULL DEFAULT 0, available_count INT NOT NULL DEFAULT 0, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_warehouse_code (warehouse_code) ); CREATE TABLE stock_transfer_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, transfer_no VARCHAR(64) NOT NULL, source_warehouse VARCHAR(32) NOT NULL, target_warehouse VARCHAR(32) NOT NULL, transfer_count INT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待执行 1-成功 2-失败, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP );这个建表方案里有几个值得注意的参数。warehouse_code做成唯一索引是为了防止并发创建重复仓库带来的脏数据。version字段不是给业务查询看的是给扣减时的乐观锁用的它在UPDATE语句里充当CAS的比对条件。available_count永远等于total_count减去sold_count但你不需要在SQL里冗余计算只要在扣减的时候保证总票数不减就行。2.2 约束一分区库存扣减不能出现负值转移仓库最容易犯的错误是“先转移再扣减”的顺序颠倒。比如郑州到武汉的仓不够了你把北京仓的票转移过去然后才扣。这个顺序在分布式环境下有一个致命的漏洞转移操作还没提交用户侧扣减已经发生了两边一合并就出现超卖。我在设计时会定死一条铁律任何扣减都必须发生在转移之后且扣减必须带上版本号。意思是业务侧先调用转移服务拿到一个转移成功的回执再执行扣减扣减的SQL必须写成“UPDATE warehouse_stock SET available_count available_count - #{count}, version version 1 WHERE warehouse_code #{code} AND available_count #{count} AND version #{version}”。affected rows为0就说明版本被别的事务改过了要么重试要么拒绝服务。这里有个Java后端常见的坑很多团队会把version检查放在Service层用select先查再update。这不是原子操作两个线程查到同一个version先后update第二个人的where条件已经失效了。正确做法是把version判断塞进SQL的where子句让数据库来做CAS。2.3 约束二转移是异步的查询允许短期不一致回到那个“买不到直达票”的场景你可能会想为什么用户查余票时系统不能实时去把其他仓的票调过来答案是查询链路过长。一次余票查询可能涉及上千个区间节点的库存汇总如果每次查询都触发一次跨仓转移数据库的写压力会直接拖垮读性能。所以转移仓库在工程上必须是异步的。常见做法是查询接口只读当前分区的available_count不做任何汇总和转移动作后台启动一个定时任务每隔几秒扫描那些即将售罄或长期低效的分区计算出需要转移的票额生成转移任务丢到消息队列里异步执行。用户看到的余票数可能是几秒前的快照但拿到票之后系统有能力在几秒内补齐库存这个短期不一致是业务可以接受的。这个决策直接决定了你后面源码的模块划分。查询模块不依赖转移模块转移模块不阻塞主流程两者之间通过数据库流水表解耦。热词里那些“12306抢票脚本”“余票监控”之所以不靠谱就是因为它们根本碰不到真正的库存系统只能靠轮询刷新页面。3. 核心链路落地RedisLua保证原子扣减异步任务衔接数据库3.1 为什么不直接用数据库乐观锁扛所有并发数据库乐观锁能保证不超卖但它扛不住高频扣减。12306高峰期每秒的扣减请求是万级甚至十万级的一次UPDATE要占用连接、要锁行、要写binlog数据库连接池很快耗尽。所以生产环境通常会用Redis前置一层把热仓库存加载到内存里扣减在Redis里完成再把结果异步刷回数据库。Redis扣减的核心是Lua脚本它保证了“检查余票、扣减、写流水”这三个动作在Redis单线程模型里是原子的。选Lua而不是用Java代码里get然后set是因为Redis的事务本身不支持回滚Pipeline请求中间一旦失败前面成功的命令不会撤销只有Lua脚本能在一个原子单元里完成全部逻辑。3.2 库存扣减的Lua脚本与Java调用参数-- KEYS[1]: 仓库库存Key例如 stock:warehouse:BJB-ZZD -- KEYS[2]: 流水Key存储转移或扣减记录 -- ARGV[1]: 本次扣减数量 -- ARGV[2]: 业务单号 -- 返回值: 1-成功 0-失败 local available redis.call(HGET, KEYS[1], available) if not available or tonumber(available) tonumber(ARGV[1]) then return 0 end redis.call(HINCRBY, KEYS[1], available, -tonumber(ARGV[1])) redis.call(HINCRBY, KEYS[1], sold, tonumber(ARGV[1])) redis.call(RPUSH, KEYS[2], ARGV[2] .. : .. ARGV[1]) return 1这段Lua脚本里有三个参数必须说清楚。KEYS[1]用的是Hash结构而不是String因为一个仓库至少有三个字段要维护——available、sold、version拆成三个String做不了一个原子的HINCRBY。KEYS[2]是流水Key你可以在Java调用时把它设置成当天的日期比如stock:transfer:20250323这样方便后续异步任务按天扫描重放。ARGV[1]是扣减数量注意它必须是整数且大于0函数入口要做参数校验否则负数扣减会在HINCRBY里直接变成增加库存。Java端调用这个脚本用Spring Data Redis的DefaultRedisScript最省事。脚本只需要在启动时初始化一次不要每次请求都重新加载脚本内容否则Redis会反复执行SCRIPT LOAD白白消耗网络和内存。Component public class StockDeductService { private static final String DEDUCT_SCRIPT local available redis.call(HGET, KEYS[1], available) if not available or tonumber(available) tonumber(ARGV[1]) then return 0 end redis.call(HINCRBY, KEYS[1], available, -tonumber(ARGV[1])) redis.call(HINCRBY, KEYS[1], sold, tonumber(ARGV[1])) redis.call(RPUSH, KEYS[2], ARGV[2] .. : .. ARGV[1]) return 1; private final DefaultRedisScriptLong deductScript; public StockDeductService(RedisTemplateString, String redisTemplate) { this.deductScript new DefaultRedisScript(); this.deductScript.setScriptText(DEDUCT_SCRIPT); this.deductScript.setResultType(Long.class); } public boolean deduct(String warehouseCode, int count, String bizNo) { Long result redisTemplate.execute( deductScript, Arrays.asList(stock:warehouse: warehouseCode, stock:flow: LocalDate.now()), String.valueOf(count), bizNo ); return Long.valueOf(1L).equals(result); } }这段Java代码踩过几个坑你照着写能少走弯路。execute方法的第三个参数必须是数组或List不能传单个字符串否则RedisCallback解析参数时会报类型错误。bizNo必须包含业务语义我习惯拼成“orderId_warehouseCode_count”这种格式方便在查流水时一眼看出是哪个订单扣了哪个仓。另外注意RedisTemplate的序列化器如果你把key的序列化器配成了Jackson存储到Redis里的key会带上包名类名前缀Lua里HGET的时候RedisTemplate帮你序列化但Lua不会两边一对不上就永远返回nil。解决办法是key和field都用StringRedisSerializer。3.3 转移任务如何从Redis落回MySQLRedis里的扣减成功了MySQL里的库存在哪里更新这里有两条链路可以走。更稳的是异步双写Redis扣减成功只是“临时占用”任务会带着扣减明细写入MQ消费端拿到消息再对数据库执行乐观锁更新。更简单的是定时对账每天一个定时任务扫描Redis流水把当天所有扣减记录批量合并成一次UPDATE操作回写MySQL再做一次Redis和MySQL的双向校验。我在实战中会选择前者因为它的延迟低数据库能在秒级追上Redis的状态。但MQ消费必须实现幂等消费端在更新数据库之前先查一遍流水表同一个bizNo如果已经存在就跳过。这一步不做的后果是消息重投会带来重复扣减用户明明买了一张票数据库里却扣了两张的库存。4. 源码实现方案从包结构到核心类手写一个可运行的转移引擎4.1 Maven工程与包结构为什么按领域而不是按三层架构拆很多Java项目的源码拆包是按controller、service、mapper三层来拆的这个结构写CRUD够用但写转移仓库这种偏业务的系统会很痛苦。三层拆法的问题是转移相关的调度逻辑、Redis逻辑、数据库逻辑散落在三个包下新来的同事看半天也不知道一个完整的转移流程串在哪里。我建议按领域拆。常见的做法是顶层分成warehouse、transfer、schedule、common四个包。warehouse包管仓库的增删改查和库存扣减transfer包管转移任务的生成、执行、补偿schedule包管定时扫描和任务调度common包只放工具类、统一返回体、异常定义。这样每个包下的类能独立自测转移逻辑不会污染到仓库查询。一个仓库转移任务的完整包结构如下新增业务时照着这个骨架往里填类就行src/main/java/com/train12306/ ├── common/ │ ├── exception/BizException.java │ └── result/Result.java ├── warehouse/ │ ├── controller/WarehouseController.java │ ├── service/StockDeductService.java │ ├── service/StockQueryService.java │ └── repository/WarehouseStockMapper.java ├── transfer/ │ ├── controller/TransferController.java │ ├── service/TransferService.java │ ├── service/TransferExecuteService.java │ ├── mq/TransferConsumer.java │ └── repository/StockTransferLogMapper.java └── schedule/ ├── StockScanner.java └── TransferTaskScheduler.java这里要说明的是controller的存在不是为了暴露HTTP接口而是为了本地调试和运维手动触发。生产环境的转移任务通常由定时任务发起但留一个手动触发的入口能让运维在紧急调配时不用改代码。很多系统上线后才发现没有手动入口只能临时写SQL这是很不专业的做法。4.2 TransferService转移动作的入口与参数说明转移的核心动作是“把A仓的库存搬给B仓”它要处理的不只是一条UPDATE而是涉及两个仓库的原子性变化。完整的转移动作是扣减Source仓的available增加Target仓的available同时写入一条transfer_log。这三个操作在数据库层面要用事务包住任何一个失败都整体回滚。Service public class TransferService { private final WarehouseStockMapper stockMapper; private final StockTransferLogMapper logMapper; private final TransactionTemplate transactionTemplate; public TransferService(WarehouseStockMapper stockMapper, StockTransferLogMapper logMapper, TransactionTemplate transactionTemplate) { this.stockMapper stockMapper; this.logMapper logMapper; this.transactionTemplate transactionTemplate; } public String transfer(String sourceWarehouse, String targetWarehouse, int count) { if (count 0) { throw new BizException(转移数量必须大于0); } String transferNo TF System.currentTimeMillis() RandomStringUtils.randomNumeric(4); transactionTemplate.executeWithoutResult(status - { int sourceRows stockMapper.deductAvailable(sourceWarehouse, count, VersionHolder.get(sourceWarehouse)); if (sourceRows 0) { status.setRollbackOnly(); throw new BizException(源仓库库存不足或版本冲突); } int targetRows stockMapper.increaseAvailable(targetWarehouse, count); if (targetRows 0) { status.setRollbackOnly(); throw new BizException(目标仓库不存在); } StockTransferLog log new StockTransferLog(); log.setTransferNo(transferNo); log.setSourceWarehouse(sourceWarehouse); log.setTargetWarehouse(targetWarehouse); log.setTransferCount(count); log.setStatus((byte) 1); logMapper.insert(log); }); return transferNo; } }这段代码里最需要注意的是TransactionTemplate而不是Transactional。Spring的Transactional默认只在抛出RuntimeException时回滚而transfer()方法内部调用了两个Mapper如果第二个Mapper失败抛的是受检异常事务是不会回滚的。TransactionTemplate把事务边界显式化setRollbackOnly 抛出BizException能确保两个仓库的变更一定同时提交或同时回滚。还有一个容易被忽略的参数是VersionHolder它是一个ThreadLocal负责在本次请求上下文中保存源仓库的最新版本号。为什么不用Mapper里查出来的旧版本因为deductAvailable的where条件需要比对最新版本而如果先在Service里select再传给Mapperselect和update之间可能有别的线程插进来修改版本号。正确做法是在Mapper的update语句里直接select版本号或者用VersionHolder在事务开启前读一次。4.3 定时扫描与MQ消费转移指令如何形成闭环只有transfer方法还不能叫“方案”因为没有人告诉它“什么时候该转移、转移多少”。这一步由调度模块接替它干两件事扫描库存水位生成转移指令。扫描周期不宜太短5秒一次足够太频繁会加重数据库查询压力转移阈值的判定也很关键我常用两个条件一个是剩余可用数低于总票数的10%且未来2小时有售票高峰另一个是当前分区客流预测明显高于另一分区。扫描器拿到数据后不直接调transfer而是丢给MQ。这么做的好处是削峰——高峰期可能同时有几百个分区需要转移如果全部同步执行数据库连接直接被占满正常售票反而被拖垮。MQ积压几分钟不影响业务因为转移本身是一个“预调整”不是“实时必须完成”的动作。消费端拉取转移指令后再去调TransferService。如果转移失败不要无限重试设置最大重试次数为3超过3次把状态置为2并写入失败原因。失败的任务会由第二天的对账任务统一处理做“反向转移”把多转的库存搬回去。这个闭环是整个方案里最容易被忽略的环节很多团队只写了转移成功的路径失败了对账完全空白最后账目越差越多。5. 实战避坑从并发扣减到数据补偿的六个翻车现场5.1 现象Redis显示库存够但数据库扣减却超卖这个是压测时最容易撞见的问题。Redis里available还剩5张一次并发来了8个请求Lua脚本拦住了3个5个放行数据库收到5条消息却扣了7行的库存。根因是消费端幂等没做。MQ在极端场景下会重复投递同一条消息消费端如果直接执行UPDATE而不先查流水表同一条扣减消息被消费两次数据库就多扣一次。解决方法是消费端先查StockTransferLogtransfer_no存在就直接ack不再执行SQL。5.2 现象扣减成功了但用户收到“订单已关闭”的提示用户端显示扣款成功票却没出。追踪日志发现Redis的扣减发生在RDB持久化之前进程重启后库存恢复到了扣减前的状态但MySQL已经扣了。根因是Redis的持久化策略和异步双写之间的时间差。解决方法是把Redis当“缓存”而不是“数据源”每次扣减后立即发MQ以数据库为准。Redis重启丢了数据就用数据库里的可用数重新加载而不是等到对账任务第二天才修。5.3 现象转移任务积压源仓库库存被搬空高峰期转移指令积压了几千条消费端慢慢消费结果发现某个热门分区的票被全部转移到另一个仓本区反而没票卖。根因是转移脚本只看库存阈值没看实时客流。解决方法是给每个仓库加一个transfer_in_progress标记位同一时间只允许一条转移任务在读这个仓。同时把“转移”和“扣减”分开上锁扣减走Redis原子操作不受影响转移在数据库层面加了行锁两个操作就不会互相踩。5.4 现象数据库连接池被扣减SQL打爆负责库存扣减的Mapper只有一个高峰期每秒上万个扣减请求全部落在它身上。数据库连接池默认配置只有10个其他查询全部阻塞。根因是没给扣减接口单独配置独立线程池。解决方法是把库存扣减的线程池和普通查询解耦扣减线程池核心线程数设为2的倍数根据CPU核数定队列容量控制在1000以内满了直接返回“繁忙”而不是继续堆积。后端的MQ还有一层缓冲用户在界面看到繁忙总比超时好。5.5 现象压测通过一上线余额就错这个最头疼UAT环境压测完全正常生产跑2小时一算账发现总票数对不上。根因是生产环境的MySQL事务隔离级别是READ_COMMITTED而UAT是REPEATABLE_READ。两种隔离级别下两个并发事务对同一个version的可见性不同导致乐观锁在UAT里拦截了冲突生产里却没拦住。解决方法是把SQL里的version比对改成“availabe_count扣减数”这个条件再配合Redis的Lua预扣不要只依赖乐观锁。生产环境上线前必须把隔离级别核对一遍REPEATABLE_READ下验证通过不代表READ_COMMITTED也通过。5.6 现象转移成功但流水缺失对账时无从查起事务里写了transfer_log但事务提交前应用宕机导致库存变了但流水没落库。根因是事务回滚条件不满足logMapper的异常被吞了。解决方法是把流水写入放在最前面——先写流水占位状态置为“执行中”再改库存。成功后更新状态为成功失败则保留“执行中”让对账任务掃描出来重放。这个顺序牺牲了一点性能但换来了账目可追溯我觉得完全值得。6. 进阶验证把源码推到Git仓库后用对账脚本证明系统没算错源码写完只代表“能跑”不代表“没算错”。验证整个转移仓库的正确性核心是一份独立的对账脚本。这份脚本不允许依赖业务代码里的任何方法只查数据库和Redis用SQL的聚合函数算一遍总数。常用的验证思路是这样的统计所有warehouse_stock表的available_count之和减去所有transfer_log里成功状态的数量之和结果必须等于0。如果不等于0说明有转移没有写流水或者流水存在但库存没变更。这个校验意义很大因为它在逻辑上把两个独立的数据源绑在了一起任何一边有遗漏都会暴露。# 通过MySQL命令行执行生产环境建议放到跳板机 mysql -h127.0.0.1 -utrain -p123456 train_ticket -e SELECT SUM(available_count) AS total_available FROM warehouse_stock; mysql -h127.0.0.1 -utrain -p123456 train_ticket -e SELECT SUM(transfer_count) AS total_transfer FROM stock_transfer_log WHERE status 1; redis-cli --scan --pattern stock:warehouse:* | xargs -L 1 redis-cli HGETALL跑完之后你会发现一个有意思的问题Redis里每个仓库的available字段累加出来和数据库里SUM的结果对不上。原因不用慌因为Redis是实时扣减后的数数据库是异步消费后的数中间必然存在一个时间差。对账看的是趋势而不是瞬时的相等。我一般会给这个对账脚本加一个允许误差范围参数比如误差在20张以内视为正常超过则触发告警并锁定相关仓库禁止转移。验证通过后记得把项目推到你自己的代码仓库用命令行演示一次完整的提交和分支管理流程。我习惯在Git仓库里维护一个release分支源码推上去之前先跑一遍JUnit集成测试确认Lua脚本和Java代码能协同工作。推送命令很简单但里边的坑在于.gitignore一定要把target/和*.log排除掉否则会把编译产物和日志文件一并推到仓库既不专业也浪费空间。Maven配置多镜像仓库可以见第4章包结构这里就不展开了。6.2 压测转移引擎控制变量才能看出真实瓶颈最后说一个我的惯性做法每次压测我只改变一个变量。比如先固定100个并发用户关闭Redis只测MySQL乐观锁的扣减吞吐再开启Redis比对两者数据差。你把Redis去掉测一遍能清楚看到数据库能扛到多少加上Redis再测一遍看看纯Redis的Lua脚本能到每秒多少笔。这两个数字之间的差就是Redis带来的收益。如果实际收益不到30%说明你的Lua脚本写得有问题或者序列化配置不对别急着加机器先回头看代码。压测结束后把结果汇总成一个表记录压测场景、并发数、TPS、错误率、数据库连接池最大活跃数。这张表不只是给领导看更是给自己下次调优留参照。我吃过一次亏上次优化完Redis脚本自测单机TPS从2万涨到5万结果一接入真实流量反而超时。复盘才发现压测机连的是本机Redis而生产Redis是主从架构写入要等从节点同步延迟高了一个数量级。后来我每次压测都用生产相同规格的Redis实例再也没翻过车。希望这些从数据模型、源码组织到压测验证的经验能帮你在做余票、库存、预约类系统时少走一点弯路。至少下次面试官问起“12306的票仓是怎么调度的”你能不慌不忙把这套方案讲清楚。本文还有配套的精品资源点击获取