1. 盲盒商城的业务逻辑和普通电商差在哪先说个我自己的观察。很多朋友一看到手办盲盒商城这个需求第一反应就是这不就是个电商系统吗商品表、订单表、购物车老套路了。真把这个项目做下来我发现盲盒商城和普通电商至少有四个本质差异如果前期没想清楚后面写代码一定会返工。第一个差异是库存模型不同。普通电商卖的是确定商品SKU、库存、价格都是确定的。盲盒商城卖的是概率一个盲盒系列里有普通款、稀有款、隐藏款每款数量不一样抽中概率也不一样。从数据库层面看库存不是简单扣一件商品而是扣一个系列下的随机款式。这就要求库存设计必须拆成两级系列库存总体可抽次数和款式库存每种款式剩余数量。第二个差异是订单和发货的映射关系。普通电商下单时订单明细已经确定。盲盒商城在下单那一刻只知道用户抽中了哪个款式但这个款式是不是真实存在、有没有被并发抢走需要在抽盒逻辑里解决。换句话说订单生成和商品确定是同时发生的但和最终发货又是弱关联的——用户抽中隐藏款系统要立刻锁定这个结果否则超发就是事故。第三个差异是用户心理预期不同。买普通商品用户在意的是我买到的东西对不对。买盲盒用户在意的是我抽的过程爽不爽。开盒动画抽中稀有款的炫耀感再来一发的冲动这些体验逻辑在技术上体现为抽盒接口延迟要快、结果要稳定、不能出现用户抽中了但系统反悔的情况。第四个差异是运营侧的重点不同。普通电商看转化率和复购率盲盒商城看的是隐藏款投放节奏、系列热度、抽盒用户的分布概率。所以管理端必须能控制概率、能看到实时的库存水位不是简单做个CRUD就行。这篇博客我直接基于一个用Java全家桶实现的实战项目来讲项目代号就叫某盲盒商城系统整体采用Spring Boot MyBatis-Plus Redis RabbitMQ这套主流技术栈。适合准备做毕设、想练手电商项目、或者对高并发下单场景感兴趣的Java后端开发。2. 技术选型与工程结构为什么是Spring Boot这套组合盲盒商城这个场景技术选型有几个硬性要求。第一抽盒并发高某个隐藏款上架瞬间可能涌入大量请求需要分布式锁和缓存兜底。第二订单创建涉及支付、库存扣减、积分变动多个环节必须保证最终一致性。第三整个系统要能承受营销活动带来的瞬时流量峰值但又不能过度设计成大型微服务架构——单机扛不住微服务又太重。基于这三点我选了Spring Boot 2.x MyBatis-Plus Redis RabbitMQ这套组合。MySQL存核心业务数据Redis扛热点和分布式锁RabbitMQ做异步解耦。这套选型在中小规模电商项目里非常务实既能撑起几万日活的商城又不会让人陷入分布式事务的泥潭。2.1 核心依赖和版本选择我的实际pom里基础依赖如下parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-amqp/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency /dependencies这里有一个细节很多人会忽略Spring Boot 2.7.x 对应的Spring Cloud版本是2021.0.x如果项目里有引入注册中心和配置中心的打算版本要匹配。我是单机部署所以没有引入Spring Cloud避免为了用而用。2.2 工程结构按业务域而非按技术层划分我见过不少项目包结构是controller、service、mapper这种纯技术分包代码一多就乱。这个盲盒商城我按业务域划分阅读和维护体验好很多com.example.blindbox ├── common // 通用工具、统一返回、异常处理 ├── config // Redis、MQ、线程池等配置类 ├── module │ ├── series // 盲盒系列 │ ├── box // 单个盲盒SKU粒度 │ ├── draw // 抽盒核心逻辑 │ ├── order // 订单 │ ├── payment // 支付与退款 │ └── user // 用户与积分每个业务域内部再分controller、service、mapper、entity、dto。这么做的好处是抽盒逻辑和订单逻辑不会互相污染后期加功能也只在对应域里动。3. 数据库模型设计盲盒、系列、款式和库存怎么建模聊完选型进入这个项目真正的核心——表设计。盲盒商城数据库设计最忌讳的就是把盲盒当成一张扁平的商品表。真实业务里有几个层级系列series是营销概念比如潮玩都市系列盲盒box是购买单元用户买一个盲盒价格是确定的款式style是隐藏在盒子里的实际内容物库存stock则贯穿系列、盲盒、款式三个层级。3.1 系列、盲盒、款式三层结构我设计的三张核心表如下系列表 blind_series字段类型说明idbigint主键series_namevarchar系列名称series_imagevarchar系列主图statustinyint1上架 0下架total_countint系列总投放量sold_countint已售数量pricedecimal单盒统一售价create_timedatetime创建时间盲盒表 blind_box字段类型说明idbigint主键series_idbigint所属系列box_namevarchar盲盒名称box_novarchar盲盒编号对外展示statustinyint1可售 0锁定款式表 blind_style字段类型说明idbigint主键series_idbigint所属系列style_namevarchar款式名称style_typetinyint1普通 2稀有 3隐藏probabilitydecimal预设权重stock_totalint该款式总库存stock_leftint该款式剩余库存imagevarchar款式图片很多新手会问盲盒表blind_box到底有什么存在意义答案是盲盒表承载的是售卖单元的概念。同一个系列下可能有标准版盲盒和豪华版盲盒两个SKU两者价格不同、包含的款式概率分布不同。如果不建blind_box表series表就得又存死价格又存死概率扩展性很差。抽盒时实际逻辑是从blind_box中确认用户买的是哪个SKU再到blind_style中按概率选一个具体款式。3.2 库存扣减的正确姿势盲盒系统的库存不是简单的减一。一次抽盒操作涉及两个库存系列总库存series.stock和款式库存style.stock_left。如果你在事务里用先查再更新的写法高并发下必出超卖。我推荐两种方案方案一推荐在SQL语句里直接做条件更新。UPDATE blind_style SET stock_left stock_left - 1 WHERE id #{styleId} AND stock_left 0如果更新影响行数为1说明扣减成功为0说明库存没了重新选款。方案二Redis预扣减。抽盒前先把该系列的库存写入Redis每次扣减用Lua脚本保证原子性。这种方式性能最强但需要处理Redis和MySQL的数据一致性。我实际用的是方案一为主、方案二为辅的混合模式。普通款抽盒走MySQL条件更新隐藏款抽盒走Redis预扣减Lua脚本。原因后面抽盒核心逻辑详细讲。3.3 订单相关表的拆分盲盒订单和普通电商订单还有一个显著区别支付前订单不绑定具体款式支付后才绑定。订单主表 blind_order字段类型说明idbigint主键order_novarchar订单号user_idbigint用户IDbox_idbigint购买的盲盒SKUseries_idbigint系列IDamountdecimal支付金额statustinyint0待支付 1已支付 2已发货 3已完成 4已退款draw_statustinyint0未抽 1已抽create_timedatetime创建时间抽盒结果表 blind_draw_result字段类型说明idbigint主键order_idbigint订单IDorder_novarchar订单号style_idbigint中奖款式IDseries_idbigint系列IDdraw_codevarchar开盒码用于验证winner_timedatetime开盒时间有人会问为什么不直接把款式ID写到订单表里因为抽盒是一个支付后行为如果用户下单不支付是不该消耗款式库存的。把抽盒状态单独拆出来可以做到支付前订单仅是购买凭证支付后才触发开盒逻辑。这个设计中如果用户拍下未支付盲盒库存不锁定方便运营侧安排库存。4. 核心代码实现抽盒、防超卖和订单幂等这一节是整篇文章的干货高潮。盲盒商城系统能不能跑得稳就看抽盒链路写得硬不硬。我把整个链路拆成三步预扣库存、随机选款、异步落单。每一步都有典型案例和坑点。4.1 预扣库存Lua脚本控制并发普通电商是先下单、后扣库存盲盒商城是先扣库存、再开盒、然后落单。因为盲盒存在隐藏款抽中隐藏款那一刻系统必须保证库存真实扣减否则后面发货根本拿不出货。隐藏款的并发扣减我使用的是Redis Lua脚本。先给出Lua逻辑local key KEYS[1] local quantity ARGV[1] local current redis.call(get, key) if not current then return -1 end if tonumber(current) - tonumber(quantity) 0 then return 0 end redis.call(decrby, key, quantity) return 1这段脚本做了什么读取库存key判断是否充足充足则一次性扣减。整个过程在Redis单线程内完成天然原子性避免了Java层分布式锁带来的性能损耗。调用时我用Redisson客户端或原生Lettuce执行public boolean preDeductStock(String seriesStockKey, int quantity) { DefaultRedisScriptLong script new DefaultRedisScript(); script.setScriptText(...上面的Lua脚本...); script.setResultType(Long.class); Long result redisTemplate.execute(script, List.of(seriesStockKey), String.valueOf(quantity)); return result ! null result 1L; }这里有个经验脚本不要每次new要缓存成单例否则并发上来时Lua脚本装载开销会拖垮速度。4.2 随机选款权重概率算法的江湖随机选款是盲盒系统最有业务味道的部分。每个系列里的款式不是等概率的普通款可能占70%稀有款占25%隐藏款占5%。选款算法的目标在剩余库存可支撑的情况下尽量让抽中的款式符合预设概率分布但也不能出现隐藏款还没卖完就早被抽走的尴尬。我采用的是权重分段随机法。先把该系列所有款式按概率权重展开成比例段再取随机值落入段内public StyleWeightDTO drawStyle(ListStyleWeightDTO styleList) { // styleList包含每个款式的styleId和权重probability double totalWeight styleList.stream() .mapToDouble(StyleWeightDTO::getProbability) .sum(); double randomVal ThreadLocalRandom.current().nextDouble(0, totalWeight); double cursor 0; for (StyleWeightDTO item : styleList) { cursor item.getProbability(); if (randomVal cursor) { return item; } } return styleList.get(styleList.size() - 1); }这个算法本身很常规真正的坑在于库存不可用时的二次选款。比如系统计算概率时隐藏款该出现的位置正好命中但隐藏款Redis库存已经扣完了怎么办我的处理是捕获库存不足信号后从剩余款式中剔除该款式重新按剩余库存的比例计算权重再抽一次。用大白话说就是抽到了没货的奖系统重新洗牌而不是直接告诉用户没货。这个处理对用户无感但能防止热门款被抽干后整个系列无法售卖。4.3 抽盒主流程与消息异步落单抽盒主流程我设计成同步异步结合同步完成扣库存和选款异步完成订单创建、通知、发货准备。流程图简化后如下用户发起抽盒请求携带boxId、userId校验用户登录态、盲盒是否可售、是否满足购买条件Redis预扣系列库存调用随机选款算法MySQL条件更新款式库存防超卖兜底写入盲盒购买记录表待支付状态发送MQ消息订单支付成功后的后续处理同步返回恭喜获得XXX款式对应的主流程核心代码大致这样Transactional(rollbackFor Exception.class) public DrawResultBO draw(BoxDrawRequest request) { // 第一步校验盲盒 BlindBox box checkBoxAvailable(request.getBoxId()); // 第二步预扣系列库存Redis boolean deducted preDeductStock(box.getSeriesId(), 1); if (!deducted) { throw new BizException(手慢了本系列已抽完); } try { // 第三步选款 StyleWeightDTO style drawService.drawStyle(box.getSeriesId()); // 第四步MySQL款式库存扣减 int rows styleStockMapper.cutStock(style.getStyleId()); if (rows 0) { throw new StockNotEnoughException(style.getStyleId()); } // 第五步生成抽盒订单与结果 BlindOrder order buildOrder(box, style, request.getUserId()); orderMapper.insert(order); DrawResult result buildDrawResult(order, style); drawResultMapper.insert(result); // 异步通知、积分发放等交给MQ rabbitTemplate.convertAndSend(blindbox.exchange, order.pay.success, order.getOrderNo()); return DrawResultBO.fromEntity(result); } catch (StockNotEnoughException e) { // 剔除库存不足款式后重抽 return redraw(box, request.getUserId(), e.getOutOfStockStyleId()); } }看到这里细心的朋友可能会问前面已经用Redis预扣库存了为什么MySQL还要再扣一次这里解释一下。Redis的扣减是快速闸门MySQL的扣减是最终防线。Redis可能在极端场景下和MySQL数据不一致例如Redis重启、数据淘汰策略MySQL条件更新WHERE stock_left 0能保证最终不超卖。两层防线并不是重复劳动而是兜底体系。4.4 支付回调的幂等性处理商城系统的支付回调是一个老生常谈但永远有人踩坑的点。盲盒商城的支付回调还有一个特殊性支付成功意味着开盒事件要被真正触发不能因为回调重复导致同一个人抽两次盒子。我的处理方式有两种标识在支付回调接口入口处处理逻辑被包裹在Transactional中。回调处理时先查询该订单号是否已经支付如果已支付则直接返回成功。代码示例Transactional public PayResult handlePayNotify(String orderNo, String txnId) { BlindOrder dbOrder orderMapper.selectByOrderNo(orderNo); if (dbOrder null) { throw new BizException(订单不存在); } // 幂等判断 if (dbOrder.getStatus() OrderStatus.PAID.getCode()) { return PayResult.success(); } // 更新订单状态 int rows orderMapper.updateStatusByOrderNo(orderNo, OrderStatus.PAID.getCode(), OrderStatus.PENDING_PAY.getCode()); if (rows 0) { // 并发回调已经被别的线程更新 return PayResult.success(); } // 处理开盒、积分发放等 distributeReward(orderNo); return PayResult.success(); }这里有个关键点支付宝、微信支付等渠道回调时如果返回异常渠道会一直重试所以回调接口绝对不能让未处理完的业务异常直接抛出给渠道。正确姿势是底层业务出错时记录日志和标记回调接口依然返回成功但内部会有定时任务去补单。这个宁可内部重试、不让渠道重推的原则对盲盒商城这种涉及抽奖的系统尤其重要——抽奖这种业务用户感知极强一旦渠道重复回调引发重复开盒客服会被投诉短信淹没。5. 前端与联调管理端、用户端和支付接口的对接要点后端系统再扎实前端联调没做好项目在评委眼里照样扣分。我做的这套盲盒商城系统前端分为用户端小程序风格页面和管理端后台管理页面。实际开发中前端和后端的联调有几个点值得单独拎出来讲。5.1 抽盒接口的交互协议设计前端抽盒需要一个友好、明确的接口文档。我提供前端的关键接口是POST /api/draw 请求参数 { boxId: 123, userId: 456 } 响应参数 { code: 0, data: { drawResultId: 789, styleName: 夜光隐藏款, styleType: 3, imageUrl: https://..., drawCode: ABC123XYZ }, msg: 成功 }后端需要明确告诉前端的不是你抽到了XA而是包括类型和图片URL方便前端渲染开盒动画。如果响应携带drawCode开盒码用户和运营都能在后续流程中验证真伪。5.2 管理端概率配置的交互管理端最重要的页面是系列概率配置。运营在页面里为每个款式设置权重值前端保存时直接将其POST到后端POST /api/admin/style/probability 请求参数 { seriesId: 1, styles: [ {styleId: 11, probability: 70}, {styleId: 12, probability: 25}, {styleId: 13, probability: 5} ] }后端在保存时必须做权重归一化校验。如果运营把所有权重加起来不等于100%给出明确提示。另外我的系统在后端保存配置时会同步刷新Redis中的款式权重缓存因为抽盒接口的选款权重是从Redis读取的避免概率配置改完不生效的情况。5.3 支付渠道对接时的参数准备商城系统的支付对接前端和后端的分工通常是前端调用后端获取支付参数后端再向支付渠道下单。联调时容易出问题的点有两个。第一金额精度。盲盒价格可能是49.5元这类带小数的金额。后端传给支付渠道时必须以分为单位传整数否则渠道会拒绝或金额错误。我在代码里用BigDecimal运算BigDecimal totalAmount box.getPrice().multiply(new BigDecimal(100)); // 转成整数分传给渠道 String amountFen totalAmount.stripTrailingZeros().toPlainString();第二回调地址。支付渠道回调地址必须是公网可访问的URL本地联调时可以用内网穿透工具但注意不要在生产环境配错。所有回调参数验签必须严格我见过太多项目图省事直接信任回调内容导致被刷单的。盲盒系统被恶意刷单的后果比普通电商更严重抽中隐藏款再申请退款库存已经消耗了会对运营造成真实损失。6. 性能与安全优化缓存策略、抢购防护和压测复盘代码能跑通只是第一步盲盒系统最怕的其实是营销活动瞬间涌进来的流量。这个项目上线前我做了几轮性能优化和安全加固踩过的坑写在这里供参考。6.1 热点数据缓存和库存预热盲盒商城有个特性一个系列上架时用户会集中点击这一个系列产生热点读取。如果用MySQL直接扛瞬时QPS超过几千就会Database打满。我在项目中做的处理是系列商品信息写入Redis缓存时间设置为活动结束时间避免热点数据过期雪崩。系列库存上架时预先写入Redis并设置一个后台定时任务每30分钟将Redis中的库存同步回MySQL。同步时用增量更新而非全量覆盖避免覆盖掉用户下单MySQL扣减的记录。款式列表按系列ID存储Hash结构key是系列IDfield是款式IDvalue是款式详情。一次抽盒所需的系列、款式、库存查询全部走Redis不穿透MySQL。6.2 抢购期间的限流和熔断隐藏款上架的那几分钟流量是最凶的。我在抽盒接口上加了两个限流手段。第一个是令牌桶限流。用RateLimiter为每个系列生成令牌桶每秒钟只允许一定数量的抽盒请求进入后端。多余的请求直接返回排队中前端配合弹窗提示。RateLimiter limiter RateLimiter.create(200); // 每秒钟200个令牌 if (!limiter.tryAcquire()) { throw new BizException(抽盒人数过多请重新尝试); }第二个是用户维度防刷。同一用户在一段时间内只能抽一定次数。这个我用Redis的INCR EXPIRE实现配合用户ID维度做计数器超过次数就提示用户抽盒过于频繁休息一下再来。对于盲盒这种带赌博心理的产品防止个别用户脚本化刷抽非常必要。6.3 并发模拟和压测复盘我用JMeter对抽盒接口做过一轮压测。本地8G内存的机器上单接口裸奔可以到500QPS左右加上Redis缓存和异步MQ后接口稳定在1300QPS核心瓶颈变成了数据库连接池。压测发现的几个问题MyBatis-Plus的批量插入性能其实一般订单表如果每秒承载大量插入建议改原生JDBC batch或者引入ShardingSphere做分表。我的系统初期数据量不大所以只优化了批量插入逻辑。MQ消费性能取决于消费者数量。默认消费者是单线程订单处理速度会拖垮抽盒接口。我在下单消费者上配置了并发消费spring: rabbitmq: listener: simple: concurrency: 10 max-concurrency: 30数据库连接池要按压测结果调整。默认HikariCP最大连接数是10肯定不够我调到了50同时注意数据库的max_connections也要同步调整。7. 踩过的坑和调优记录从能跑到稳跑最后分享几个这个项目里真实踩过的坑。这些坑在教科书里基本找不到但每一个都让我花了不少调试时间。7.1 事务范围过大导致锁等待超时最开始我没想清楚抽盒主流程里的事务边界把Redis预扣库存、MySQL扣减库存、订单插入全部包在一个大事务里。结果并发上来后MySQL行锁竞争激烈大量请求报Lock wait timeout exceeded。后来我把事务拆细Redis预扣库存放在事务外事务内只做MySQL条件更新、订单插入、结果写入。这样做的好处是即使某个款式库存不足需要重抽也不会因为整个大事务回滚而把Redis已扣的库存还回去——不然还得额外补偿逻辑复杂。7.2 Redis库存预热和MySQL实际数据不一致上线第二天我发现某系列在管理端看到剩余库存240但Redis里的库存已经扣到负数了。排查半天原因是Redis预热时用了系列的total_count而运营在后台调整过系列总投放量没有同步更新Redis。从那以后所有库存预热操作都统一走一个服务由运营后台直接调用Redis刷新接口避免出现多个写入路径。7.3 隐藏款概率参数被前端窥探有段时间我图方便把抽盒概率配置直接放在查询接口里返回给前端渲染。结果有用户抓包看到某个隐藏款概率是0.5%之后那个系列再无人问津口碑崩了。这个教训很惨痛概率配置是内部敏感数据必须放到管理端接口而不是用户端接口字段也绝不能暴露。后来我把概率字段从用户端查询DTO中彻底移除只返回款式本身对应的image和name。7.4 退款后的库存回补盲盒商城有一个特殊业务用户抽中隐藏款后觉得不满意退款了部分支付渠道允许这时候隐藏款的库存已经被消耗如果直接退钱隐藏款就永久少了一个。我采用的方案是退款不直接把库存回补到款式库里而是统一回流到一个活动补偿池在下一次新系列上架前由运营手动决定是否释放。原因是隐藏款数量直接关系到宣传文案的抽中率不做补偿池会导致实际概率偏离宣传值继而引发舆情风险。8. 源码分享项目结构亮点和使用说明项目代码整理完我直接分享一个可直接运行的基础版本。整体目录结构在前面的工程结构里已经展示过了这里补充三个项目里最能体现设计水平的类。第一个是抽盒策略接口把选款算法抽象成策略方便以后扩展十连抽定向款抽盒等玩法public interface DrawStrategy { StyleWeightDTO draw(ListStyleWeightDTO candidates, int randomSeed); }第二个是库存扣减服务的接口把Redis预扣、MySQL兜底、补偿池这几层封装起来避免业务层直接和底层存储耦合public interface StockService { boolean deductSeriesStock(Long seriesId, int quantity); boolean deductStyleStock(Long styleId, int quantity); void releaseCompensationStock(Long seriesId, int quantity); }第三个是统一响应结果所有前后端交互都走这个对象保证状态码、消息、数据的格式一致。这块看起来基础但对联调效率影响很大。Data public class ApiResponseT { private int code; private String msg; private T data; public static T ApiResponseT ok(T data) { ApiResponseT resp new ApiResponse(); resp.code 0; resp.data data; return resp; } // 其他省略 }使用项目时需要注意的几点本地启动需要准备MySQL 5.7、Redis 5.0、RabbitMQ 3.8。数据库初始化脚本在项目doc/sql目录按顺序执行即可。配置文件application.yml中的Redis、MQ连接信息按本地环境修改。支付回调相关代码用的是模拟实现真实对接需要替换为具体渠道SDK和验签逻辑。应用这份源码时我建议重点关注抽盒主流程和库存扣减这两部分。它们和普通电商项目的差异最大也是最容易被面试官追着问的点。拿到源码后不要只import跑通就完事试着改一改、加一加需求比如增加十连抽功能、增加系列组合购买折扣你会对这系统有更深的理解。对我来说盲盒商城系统最有意思的地方在于它把电商的确定性交易和游戏的随机性体验揉在了一起技术上一下子就多了很多可以琢磨的空间。希望这篇博客和这份源码能帮到正在做类似项目的朋友。