高并发下的订单和库存处理几乎是每一家电商公司从单体走向分布式之后第一个绕不开的大坎。很多团队在日订单量几百上千的时候代码怎么写都能跑库存扣减直接用数据库UPDATE一把梭也没出什么乱子。可一旦上了营销活动瞬时流量冲上来第一波死掉的往往不是网站页面而是那个看起来最不起眼的库存表。CPU被打满、行锁堆积、订单重复下单、库存扣成负数问题接二连三地冒出来。这篇文章我就围绕高并发场景下的订单和库存处理方案这一核心命题从问题本质、方案选型、落地细节到避坑实录逐层拆解一套经过实战检验的处理思路。如果你正在设计下单链路或者当前系统已经出现库存超卖、接口响应变慢、订单状态混乱等症状这篇文章会很适合你。1. 问题的本质库存扣减为什么这么难1.1 核心矛盾在两件事上高并发订单库存处理的难点表面看是并发两个字本质上其实是两件事状态竞争和数据一致性。我们可以把一次下单看成一次状态转移用户发起购买意图系统需要把有货变成已锁定或已扣减同时还要把订单状态从待创建推进到待支付甚至已支付。问题在于同一个SKU在同一时刻有成千上万个请求都在抢着执行这同一个状态转移谁先成功、谁失败系统必须有一个明确的裁决机制。而流量一旦放大这个裁决本身就成了瓶颈。另外一件事是数据一致性。电商系统里的库存不像纯聊天消息丢了还能重发库存扣多了就是真金白银的损失扣少了又会引起超卖。而要保证不多扣、不少扣、不冲突最朴素的做法是加锁串行化但这恰恰和高并发天然对立。整条技术链路的几乎所有方案本质上都是在围绕如何既保持一定的并发度又能守住一致性底线来找平衡。1.2 一个典型的崩溃链路我在某个模拟项目中做过压测。商品库存1000件预热了200万UV的流量集中在10秒内涌入下单接口。当时用的是最传统的方案先查数据库库存再插入订单最后更新库存。整个链路跑下来现象非常典型数据库CPU使用率瞬间飙到100%大量UPDATE语句堆积在行锁上订单表出现重复记录同一个用户抢到了同一个SKU下多单库存被扣成-358超卖严重下单接口RT从50毫秒一路涨到8秒大量请求直接超时。这个问题的根源并不在数据库本身而在于查询扣减这个操作没有做原子化处理。多个请求同时读到库存有余量然后各自扣减数据的正确性自然就崩了。1.3 处理方案在设计前先回答的三个问题不管选什么技术栈设计高并发订单库存方案之前都得先回答下面三个问题扣减时机选在哪一步下单时扣、支付时扣、还是发货时扣这直接决定了库存虚占量、订单取消率、超卖风险等一系列问题。扣减操作是否原子化也就是多个请求同时进来系统能不能保证只有一个请求扣减成功其余全部失败或排队。如果中间环节失败怎么对齐库存扣了但订单没建订单建了但没支付支付了但库存被释放这些都需要一套对账机制来兜底。这三个问题理清楚了后面选型才不会摇摆。很多团队一上来就套复杂的MQ和分库分表其实连扣减时机都没定明白最后思路越做越乱性能也没上去。2. 扣减时机的三种主流方案对比2.1 下单扣减、支付扣减、预占扣减主流的库存扣减方案大致分三类每一类都有对应的业务场景和代价。下单即扣减用户提交订单时直接扣减库存。优点是实现简单不会出现下单成功但支付时发现没货的问题。缺点是会被恶意下单或犹豫型用户大量占库存导致真实买家看到缺货而仓库里其实压着大量未支付订单的库存。这种方案更适合秒杀类、稀缺类商品因为这类场景宁可放弃一部分支付转化也要保证下单成功即有货。支付时扣减用户完成支付动作时再扣库存。优点是库存占用时间短支付率是真实购买意愿的直接反映。缺点在于瞬间高并发时大量未支付订单已经把系统压力顶上去了到支付阶段库存可能已经没了用户支付完事才发现订单被取消体验非常差。这个方案比较适合客单价高、决策周期长、库存相对宽裕的商品。预占扣减两段式下单时先把库存锁定一定时间比如15分钟锁定数量不计入可售库存但也不释放给其他人用户支付成功后再从锁定库存里转为实际消耗支付超时或取消则自动释放锁定的库存。这套方案兼顾了可售库存的准确性和用户支付的灵活性是目前主流电商平台用得最多的一种模型。三种方案没有绝对优劣核心在于你服务的业务模型是什么。我自己做过的多数项目最终都倾向于预占扣减因为它最符合用户和平台的博弈逻辑——用户需要思考时间平台需要避免库存被无效占用太久。2.2 预占扣减的状态流转和核心表设计预占扣减涉及两个关键概念可售库存和锁定库存。举个例子一个SKU备货100件其中一个用户下单锁了3件那么此时可售库存显示97件但库存总量仍然100件。用户支付成功后锁定库存释放到出库环节的已售库存里系统再把这3件商品安排发货。在数据库层面通常需要一张库存流水表来承载这个状态流转。核心字段大概长这样sku_id商品维度标识change_type变动类型下单锁定、支付确认、超时释放、取消释放、后台调整change_quantity变动数量正数为增、负数为减order_no关联订单号created_at变动时间所有库存变更都落到流水表里而库存汇总表只保存实时数值。这样做的好处是任何环节出问题都能追溯某个订单的锁定记录在不在、有没有释放过、释放数量对不对一查流水就清楚了。2.3 方案选型时还要考虑的几个隐藏成本选扣减时机很多人只看业务功能忽略了三块隐藏成本超时释放的兜底逻辑。预占扣减必须有订单超时关闭的机制并且在关闭订单后可靠地执行退回锁定库存操作。如果订单关闭了但库存没退回时间久了可售库存会越缩越少。库存预热和对账。方案越好用链路越长。比如下单锁定、支付确认、物流扣减每一步都要有对应的补偿和对账任务否则某一个环节失败就会产生幽灵库存或幽灵订单。客服运营侧的可见性。一旦库存变成锁定/可售/已售多个状态客服在处理用户问题的时候必须能看到这些状态否则用户问为什么明明有货就是下不了单客服也一脸懵。所以方案选型不光是技术评估更多还是业务链路能不能承受这种复杂度。低并发的小型商城下单即扣减其实就够了完全没必要为了追求架构的先进感去引入一堆状态机。3. 防超卖的核心实现Redis缓存与原子扣减3.1 为什么数据库扣减扛不住先看最传统的数据库扣减方式UPDATE inventory SET quantity quantity - 1 WHERE sku_id ? AND quantity 0;这条SQL对于低并发场景是对的因为quantity 0条件天然防止扣成负数。但在高并发下所有请求都会盯住同一行记录MySQL的InnoDB引擎只能通过行锁一个接一个地执行UPDATE大量线程排队等待锁的释放。压测数据里单行UPDATE的TPS最多也就几百到一千多一旦流量上万数据库就基本趴窝了。所以业界普遍的做法是把库存扣减的热点从数据库转移到更高速的存储层里当前最通用的组件就是Redis。3.2 用Redis的Lua脚本保证原子扣减Redis单线程处理命令的特性让它天然适合做判断扣减这种原子操作。但要注意单纯用GET再DECR两步走是不行的因为中间有并发窗口必须把判断和扣减放进同一个Lua脚本里让Redis原子地执行。我常用的Lua脚本如下-- KEYS[1]: 商品库存key -- ARGV[1]: 扣减数量 if redis.call(EXISTS, KEYS[1]) 1 then local stock tonumber(redis.call(GET, KEYS[1])) if stock tonumber(ARGV[1]) then redis.call(DECRBY, KEYS[1], ARGV[1]) return 1 else return 0 end else return -1 end这段脚本的逻辑核心就是库存充足才扣减否则直接返回失败。因为整个脚本在Redis内部是串行执行的所以不会出现两个请求同时判断库存有余量、然后一起扣成功的情况。Java侧配合使用的代码大致如下private static final DefaultRedisScriptLong DEDUCT_STOCK_SCRIPT new DefaultRedisScript(STOCK_LUA, Long.class); public boolean deductStock(String stockKey, int quantity) { Long result redisTemplate.execute( DEDUCT_STOCK_SCRIPT, Arrays.asList(stockKey), String.valueOf(quantity) ); return Long.valueOf(1).equals(result); }注意一个细节脚本返回-1表示key不存在。这个状态通常说明缓存没有预热成功或已被删除业务侧需要触发回源加载数据库库存而不是简单当作扣减失败处理。很多人在这个返回值上踩过坑把缓存失效当成库存不足用户明明看到有货却下单失败。3.3 库存缓存与数据库之间的回源策略Redis的库存不要一把梭全量加载到缓存里更稳妥的做法是按需预热。比如商品详情页被访问时异步检查该sku的库存key是否存在不存在则从数据库加载可售库存并设置过期时间。这样既避免了大促时全量预热耗费时间又能让不热门的商品不占用Redis内存。回源时要小心一个覆盖问题如果数据库库存是100缓存key过期了此时有一个请求正在执行扣减另一个请求回源加载了100覆盖进去就会把扣减后的数值重新顶回去导致超卖。解决办法是回源时使用SETNX而非SET如果key已存在就放弃加载。另外给库存key设置过期时间时要留足余量比如10分钟过期时间会比5分钟安全得多避免热点key频繁回源。3.4 Redis不可用时的降级方案任何引入Redis的方案都要回答一个问题Redis挂了怎么办我的建议是宁可牺牲一点可用性也不能牺牲一致性。Redis不可用时的降级方案可以分为两档普通商品直接走数据库扣减此时并发量通常可控数据库的压力也能承受。大促热点商品降级到限流拒绝策略即直接提示用户稍后再试。不要试图在这种情况下强行依赖数据库去兜底热点SKU的数据库扣减大概率会打崩整个库牵连其他商品的正常下单。还有一个容易忽略的点Redis和数据库的一致性。我见过不少团队上了Redis之后数据库里的库存数值形同虚设最后Redis数据一丢整个库存账目全乱了。正确做法是Redis只作为扣减校验的前端层所有经过Redis扣减的流水都必须异步写一份到数据库库存流水表中这样Redis即使清了缓存也能通过流水重建库存数据。4. 订单与库存的一致性保障方案4.1 一个典型的订单库存分布式事务困境订单与库存一旦分离到不同的存储或服务里就会产生分布式事务问题。最典型的场景是这样的用户下单请求进来了先扣Redis库存扣减成功后开始插入订单记录。此时如果插入订单失败库存就凭空少了一部分用户没有得到订单平台也丢了这个库存。反过来也一样订单创建成功但库存扣减超时或失败用户看到订单存在系统里却没有真实的库存后续发货的时候就会卡住。解决这个问题的核心思路不是强一致而是最终一致 对账兜底。具体到代码层面我先说一下我自己惯用的处理流程请求进入下单接口先通过Redis原子扣减库存扣减成功后创建一条预订单记录状态为待确认并携带本次扣减的唯一业务流水号预订单落库成功后再异步通知订单服务真正创建正式订单正式订单创建成功将预订单状态更新为已确认如果正式订单创建失败触发库存回补逻辑并把预订单标记为已回补定时任务扫描一段时间内仍未确认的预订单进行状态判断和补偿。这种设计的好处是把库存扣了和订单建了解耦成两个步骤中间通过预订单和流水号把它们关联起来。任何一个环节失败都有据可查有专门的补偿任务去恢复一致性。4.2 状态机是订单一致性的骨架订单系统的状态流转建议一开始就引入状态机而不是散落各处用if-else判断。比如一个标准订单的状态机至少包含待支付预订单已确认等待用户支付已支付用户支付成功库存进入待出库状态已取消用户主动取消或超时关闭锁定库存释放已发货仓库发货库存正式出库已完成用户确认收货交易闭环售后中退款/退货流程启动可能需要回补库存状态机的好处不仅仅是代码结构清晰更重要的是它能定义合法状态转移路径。比如已取消的订单不能直接跳到已发货这种非法状态流转会在代码层面被拦截避免脏数据扩散。我见过不少团队的订单表状态字段就是简单的int代码里到处散落着if (order.status 2) doSomething()到了后来加新状态时根本不知道会有多少地方被影响。引入状态机之后每个状态变更都走统一入口相关的库存操作、流水记录、消息推送全都能挂在这一个口子上。4.3 定时对账任务一致性兜底的关键不管前面设计得多么严密线上总会遇到各种极端情况进程莫名其妙被杀掉了、消息积压了、回调超时了、开发上线时把接口调错了等等。这时候唯一的救命稻草就是定时对账任务。我的对账任务分为三个级别分钟级扫描待支付订单超过支付时限则关闭订单并释放库存。这保证锁定的库存能被及时回收。小时级扫描已支付但物流系统仍未扣减出库的订单核对库存流水同时核对Redis库存和数据库流水之间的差额。日级全量核对库存台账、订单台账、流水台账三者是否一致输出差异报表给运营人工复核。日级对账可能在手工处理的传统企业里不太必要但凡是和线上资金、库存相关的系统这个任务绝对值得投入开发成本。一套指标维度多、告警精准的对账脚本在故障排查时提供的价值甚至超过监控大盘。4.4 消息队列在下单链路中的角色很多方案会把MQ放在下单链路里做主流程比如下单成功-发送消息-订单服务消费创建订单。我的经验是消息队列不要参与主链路的数据强一致操作它更适合做异步解耦和流量削峰。原因很简单MQ会增加链路的长度和不确定性。万一消费者挂了、消息丢失或者重复投递用户端会直接感知到下单异常。所以我的做法是核心的下单、扣库存、创建订单仍然同步处理保证用户能实时看到结果MQ只用来处理非实时性的通知任务比如发短信、推送物流信息、更新推荐系统的行为数据等。至于流量削峰下单接口本身就应该做限流而不是指望着把请求先全揽进MQ里慢慢消化。大流量先削掉能进入业务逻辑的请求基本都是峰值内可服务的这样整个系统都能处于可控状态。5. 高并发下单接口的整体架构落地方案5.1 分层保护网关层、应用层、数据层高并发下每一个层级的防护目标不一样不能把希望寄托在某一层单独扛住所有压力。我的通用分层思路是网关层做全局限流、IP维度黑白名单、接口维度流量控制把明显恶意或重复的请求挡在最前面。应用层做热点SKU维度的本地限流比如单机每秒最多处理100个某SKU的下单请求以及基于分布式锁的库存预校验。数据层Redis扛库存扣减的热点操作数据库负责持久化和对账。以某次模拟大促为例订单接口每秒承接的请求量是5000左右网关层先过滤掉一部分非法的或重复提交的请求把真正进入逻辑的流量压到3000。应用层每个节点再按SKU维度限流最终真正落库和扣Redis的请求约每秒2000这个量级在加了索引和分表之后数据库是可以平稳承接的。5.2 接口层的防重设计在高并发下用户重复提交和系统重复下单是两个不同的概念。前者是用户手一抖点了两次后者是服务端的重试机制或消息重复投递导致的。无论哪个防止重复下单都必须在代码层面做掉。我的做法是在进入下单逻辑前先做一次分布式幂等校验// 幂等key用户ID 商品SKU 本次提交的请求唯一标识 String idempotentKey userId : skuId : clientRequestId; Boolean firstSubmit redisTemplate.opsForValue() .setIfAbsent(idempotentKey, 1, Duration.ofMinutes(30)); if (!Boolean.TRUE.equals(firstSubmit)) { throw new RepeatSubmitException(重复提交请勿频繁操作); }这个幂等key的过期时间要和预订单超时关闭时间对齐确保订单关闭后用户再次购买同一商品时不会因为幂等key还在而被拦截。还有一种更严格的做法在下单请求的token里嵌入本次请求的唯一标识由前端生成并提交后端利用数据库的唯一索引来兜底。user_id sku_id request_id建联合唯一索引如果插入时出现唯一键冲突直接判定为重复请求。5.3 热点SKU隔离和本地缓存大促活动中真正产生高并发的SKU数量其实并不多通常几十个到几百个而已但它们占了绝大部分流量。把这些热点SKU和普通SKU放在同一个链路里处理普通商品的请求会被热点商品的加载拖累。我习惯的做法是在缓存层面给热点SKU建单独的key前缀比如hot_stock:skuId并且在应用层面预热一份SKU的本地缓存Caffeine本地缓存里存的是该SKU的库存判断阈值而不是库存数值本身。比如某热点SKU设定单机本地最多放行1000个请求这1000个请求再到Redis去扣减其余的直接快速返回拥挤请稍后重试。这种做法本质上是把远端压力转化为本地提前拦截对保护后端非常有帮助。本地缓存要注意避免内存占用过高的问题只针对配置了白名单的热点SKU生效并且定期刷新配置不热了就及时摘除防止商品热度下降后仍然占用本地内存。5.4 数据库层面的辅助手段即使Redis扛住了绝大部分读和扣减操作数据库仍然需要处理预订单插入、状态更新和库存流水入账等写操作。这些写操作虽然没有库存扣减那样的单行热点但高并发下同样可能把数据库压垮。我自己处理数据库压力的经验有几点订单表按订单号做哈希分表比如拆64张表避免单表数据量过大导致的索引性能衰减。插入操作异步化预订单的落库可以先用内存队列缓存一批批量写入数据库减少小事务的开销。关键查询走只读从库订单列表、库存查询这些只读操作走从库主库专心处理写操作避免慢查询拖垮写入性能。控制单事务的范围一个事务里只做必要的写入不要把远程调用、消息发送等耗时的逻辑放在事务里否则事务时间越长锁冲突概率越大。还有一个经常被忽略的点数据库连接池的大小要合理设置。比如服务实例数是20个每个实例连接池配置50那就是1000个数据库连接。数据库能同时处理的连接数是有限的连接数越大不一定性能越好反而可能造成上下文切换开销过大。连接池建议控制在CPU核数*2到CPU核数*4之间留出余量即可。6. 实战中的常见问题与排查技巧6.1 疑难杂症的定位思路高并发的故障往往不会只挂在某一个点上更多时候是多个组件互相影响。我这里整理了几个典型的排查场景和思路非常实用。场景一Redis CPU突然飙升请求大量超时先别急着加Redis节点先查是不是有大key操作。库存扣减的Lua脚本是O(1)级别的不会导致CPU飙升更常见的情况是某个开发为了省事把几千个SKU的库存放在一个大Hash里然后遍历这个Hash做扣减。这种操作会瞬间打满Redis的单线程CPU。经验做法是一个SKU一个key不要共用一个大key。场景二订单创建成功但库存流水缺失这类问题多半出在异步任务丢失上。排查思路是先去预订单表看状态如果预订单是已确认但库存流水表里没有对应记录就说明订单创建成功后的流水写入这个环节出了问题。解决办法是给订单已确认和库存流水已写入这两个状态之间加一个事务性绑定要么同时成功要么同时失败。场景三同一用户同时提交了两个订单都扣了库存这种问题就是幂等key没生效。排查时先看请求的唯一标识是否由前端传入并透传到了后端再看幂等校验是否放在扣库存之前。很多团队把幂等校验放在了订单创建之后实际已经晚了——库存早就扣了。6.2 排查工具和命令清单排查高并发链路问题没有趁手的工具会很痛苦。我个人常用的排查手段包括redis-cli --latency快速查看Redis响应延迟redis-cli --bigkeys扫描大key定位Redis慢查询的元凶SHOW PROCESSLIST查看MySQL当前运行的SQL找慢查询和锁等待EXPLAIN分析核心SQL确认是否命中联合索引Arthas结合trace命令定位应用层接口耗时分布另外强烈建议下单链路的所有关键步骤都打上链路日志traceId贯穿全链路不要靠猜测来排查问题。日志里需要包含请求参数、库存扣减结果、订单创建结果、耗时统计。有了这些数据绝大多数问题可以在一分钟内锁定。6.3 常见问题速查表症状可能原因排查重点解决方案库存扣成了负数缺少原子化扣减race condition扣减操作是否用了事务/Lua使用Redis Lua脚本或SQL带条件扣减库存扣减成功但订单未生成跨服务调用失败没有补偿机制预订单状态、流水记录引入最终一致方案定时对账同一用户重复下单幂等校验缺失或失效幂等key是否在扣库存前校验引入分布式幂等锁唯一索引兜底下单接口RT突然拉长数据库行锁堆积或Redis阻塞慢SQL、Redis bigkey热点SKU隔离、加索引、减小事务缓存key失效后库存不准并发回源覆盖已扣减数值回源是否使用SETNX回原使用SETNX给key设置长过期时间大促时普通商品被热点商品拖垮缺少热点隔离链路日志看慢请求集中在哪些SKU热点SKU本地缓存限流、单独兜底策略6.4 线上故障的止损三板斧就算方案设计得再完善线上还是会出现意料之外的情况。这时候最重要的是快速止损保住数据正确性而不是急着修复根因。第一招直接关闭下单入口或切到全站只读模式把流量彻底挡住先保住数据库和Redis不被打挂。第二招临时调低库存扣减的Redis并发上限。如果库存扣减链路本身是健康的只是下游订单创建扛不住可以降低下单接口的放行比例让系统在半流量的状态下先跑着。第三招开启人工对账。如果已经发生了超卖或库存错乱立刻启动订单一对一对账把受影响的数据捞出来人工或脚本修复。不要指望着自动补偿能处理所有边界情况大故障面前人工介入反而是最快的。7. 写在最后的实操心得整个方案从设计到落地我自己最大的感受是高并发下的订单库存处理拼的不是用了什么高深组件而是每个环节是否都有明确的状态定义和兜底逻辑。RedisLua的原子扣减是防超卖的基石但如果没有预订单、状态机、定时对账这套组合拳库存和订单迟早会在某一次故障中走丢。很多团队花大力气优化了扣库存的性能却忽略了订单状态与库存流水的一致性等到对不上账时才发现问题根本不是出在性能上而是数据本身已经乱了。还有一点想提醒的是不要把方案设计得过度复杂。如果你的业务并发根本不高直接靠数据库事务扣减就够了。架构是为业务服务的不是用来展示技术肌肉的。我自己见过不少团队明明一天的订单量才几千却硬上了一套Redis库存异步对账分库分表的组合结果维护成本远超收益。最后分享一个小经验每次大促或活动上线前一定要做一次完整的库存扣减链路演练模拟Redis宕机、数据库死锁、消息积压这些场景。准备得再充分的方案也只有在故障面前才能暴露真正的问题。这套演练我做过很多轮每次都能至少抓出一两个平时完全想不到的边界缺陷。高并发系统从来不是写出来的是不断演练和救火趟出来的。以上是我在高并发订单和库存处理方案上的一些实践总结。如果你正在做类似的设计希望能给你提供一些可落地的思路。每个系统的业务场景不同方案细节会有差异但只要守住了原子扣减、最终一致、兜底对账这三条底线系统的大方向就不会歪。
高并发下的订单和库存处理几乎是每一家电商公司从单体走向分布式之后第一个绕不开的大坎。很多团队在日订单量几百上千的时候代码怎么写都能跑库存扣减直接用数据库UPDATE一把梭也没出什么乱子。可一旦上了营销活动瞬时流量冲上来第一波死掉的往往不是网站页面而是那个看起来最不起眼的库存表。CPU被打满、行锁堆积、订单重复下单、库存扣成负数问题接二连三地冒出来。这篇文章我就围绕高并发场景下的订单和库存处理方案这一核心命题从问题本质、方案选型、落地细节到避坑实录逐层拆解一套经过实战检验的处理思路。如果你正在设计下单链路或者当前系统已经出现库存超卖、接口响应变慢、订单状态混乱等症状这篇文章会很适合你。1. 问题的本质库存扣减为什么这么难1.1 核心矛盾在两件事上高并发订单库存处理的难点表面看是并发两个字本质上其实是两件事状态竞争和数据一致性。我们可以把一次下单看成一次状态转移用户发起购买意图系统需要把有货变成已锁定或已扣减同时还要把订单状态从待创建推进到待支付甚至已支付。问题在于同一个SKU在同一时刻有成千上万个请求都在抢着执行这同一个状态转移谁先成功、谁失败系统必须有一个明确的裁决机制。而流量一旦放大这个裁决本身就成了瓶颈。另外一件事是数据一致性。电商系统里的库存不像纯聊天消息丢了还能重发库存扣多了就是真金白银的损失扣少了又会引起超卖。而要保证不多扣、不少扣、不冲突最朴素的做法是加锁串行化但这恰恰和高并发天然对立。整条技术链路的几乎所有方案本质上都是在围绕如何既保持一定的并发度又能守住一致性底线来找平衡。1.2 一个典型的崩溃链路我在某个模拟项目中做过压测。商品库存1000件预热了200万UV的流量集中在10秒内涌入下单接口。当时用的是最传统的方案先查数据库库存再插入订单最后更新库存。整个链路跑下来现象非常典型数据库CPU使用率瞬间飙到100%大量UPDATE语句堆积在行锁上订单表出现重复记录同一个用户抢到了同一个SKU下多单库存被扣成-358超卖严重下单接口RT从50毫秒一路涨到8秒大量请求直接超时。这个问题的根源并不在数据库本身而在于查询扣减这个操作没有做原子化处理。多个请求同时读到库存有余量然后各自扣减数据的正确性自然就崩了。1.3 处理方案在设计前先回答的三个问题不管选什么技术栈设计高并发订单库存方案之前都得先回答下面三个问题扣减时机选在哪一步下单时扣、支付时扣、还是发货时扣这直接决定了库存虚占量、订单取消率、超卖风险等一系列问题。扣减操作是否原子化也就是多个请求同时进来系统能不能保证只有一个请求扣减成功其余全部失败或排队。如果中间环节失败怎么对齐库存扣了但订单没建订单建了但没支付支付了但库存被释放这些都需要一套对账机制来兜底。这三个问题理清楚了后面选型才不会摇摆。很多团队一上来就套复杂的MQ和分库分表其实连扣减时机都没定明白最后思路越做越乱性能也没上去。2. 扣减时机的三种主流方案对比2.1 下单扣减、支付扣减、预占扣减主流的库存扣减方案大致分三类每一类都有对应的业务场景和代价。下单即扣减用户提交订单时直接扣减库存。优点是实现简单不会出现下单成功但支付时发现没货的问题。缺点是会被恶意下单或犹豫型用户大量占库存导致真实买家看到缺货而仓库里其实压着大量未支付订单的库存。这种方案更适合秒杀类、稀缺类商品因为这类场景宁可放弃一部分支付转化也要保证下单成功即有货。支付时扣减用户完成支付动作时再扣库存。优点是库存占用时间短支付率是真实购买意愿的直接反映。缺点在于瞬间高并发时大量未支付订单已经把系统压力顶上去了到支付阶段库存可能已经没了用户支付完事才发现订单被取消体验非常差。这个方案比较适合客单价高、决策周期长、库存相对宽裕的商品。预占扣减两段式下单时先把库存锁定一定时间比如15分钟锁定数量不计入可售库存但也不释放给其他人用户支付成功后再从锁定库存里转为实际消耗支付超时或取消则自动释放锁定的库存。这套方案兼顾了可售库存的准确性和用户支付的灵活性是目前主流电商平台用得最多的一种模型。三种方案没有绝对优劣核心在于你服务的业务模型是什么。我自己做过的多数项目最终都倾向于预占扣减因为它最符合用户和平台的博弈逻辑——用户需要思考时间平台需要避免库存被无效占用太久。2.2 预占扣减的状态流转和核心表设计预占扣减涉及两个关键概念可售库存和锁定库存。举个例子一个SKU备货100件其中一个用户下单锁了3件那么此时可售库存显示97件但库存总量仍然100件。用户支付成功后锁定库存释放到出库环节的已售库存里系统再把这3件商品安排发货。在数据库层面通常需要一张库存流水表来承载这个状态流转。核心字段大概长这样sku_id商品维度标识change_type变动类型下单锁定、支付确认、超时释放、取消释放、后台调整change_quantity变动数量正数为增、负数为减order_no关联订单号created_at变动时间所有库存变更都落到流水表里而库存汇总表只保存实时数值。这样做的好处是任何环节出问题都能追溯某个订单的锁定记录在不在、有没有释放过、释放数量对不对一查流水就清楚了。2.3 方案选型时还要考虑的几个隐藏成本选扣减时机很多人只看业务功能忽略了三块隐藏成本超时释放的兜底逻辑。预占扣减必须有订单超时关闭的机制并且在关闭订单后可靠地执行退回锁定库存操作。如果订单关闭了但库存没退回时间久了可售库存会越缩越少。库存预热和对账。方案越好用链路越长。比如下单锁定、支付确认、物流扣减每一步都要有对应的补偿和对账任务否则某一个环节失败就会产生幽灵库存或幽灵订单。客服运营侧的可见性。一旦库存变成锁定/可售/已售多个状态客服在处理用户问题的时候必须能看到这些状态否则用户问为什么明明有货就是下不了单客服也一脸懵。所以方案选型不光是技术评估更多还是业务链路能不能承受这种复杂度。低并发的小型商城下单即扣减其实就够了完全没必要为了追求架构的先进感去引入一堆状态机。3. 防超卖的核心实现Redis缓存与原子扣减3.1 为什么数据库扣减扛不住先看最传统的数据库扣减方式UPDATE inventory SET quantity quantity - 1 WHERE sku_id ? AND quantity 0;这条SQL对于低并发场景是对的因为quantity 0条件天然防止扣成负数。但在高并发下所有请求都会盯住同一行记录MySQL的InnoDB引擎只能通过行锁一个接一个地执行UPDATE大量线程排队等待锁的释放。压测数据里单行UPDATE的TPS最多也就几百到一千多一旦流量上万数据库就基本趴窝了。所以业界普遍的做法是把库存扣减的热点从数据库转移到更高速的存储层里当前最通用的组件就是Redis。3.2 用Redis的Lua脚本保证原子扣减Redis单线程处理命令的特性让它天然适合做判断扣减这种原子操作。但要注意单纯用GET再DECR两步走是不行的因为中间有并发窗口必须把判断和扣减放进同一个Lua脚本里让Redis原子地执行。我常用的Lua脚本如下-- KEYS[1]: 商品库存key -- ARGV[1]: 扣减数量 if redis.call(EXISTS, KEYS[1]) 1 then local stock tonumber(redis.call(GET, KEYS[1])) if stock tonumber(ARGV[1]) then redis.call(DECRBY, KEYS[1], ARGV[1]) return 1 else return 0 end else return -1 end这段脚本的逻辑核心就是库存充足才扣减否则直接返回失败。因为整个脚本在Redis内部是串行执行的所以不会出现两个请求同时判断库存有余量、然后一起扣成功的情况。Java侧配合使用的代码大致如下private static final DefaultRedisScriptLong DEDUCT_STOCK_SCRIPT new DefaultRedisScript(STOCK_LUA, Long.class); public boolean deductStock(String stockKey, int quantity) { Long result redisTemplate.execute( DEDUCT_STOCK_SCRIPT, Arrays.asList(stockKey), String.valueOf(quantity) ); return Long.valueOf(1).equals(result); }注意一个细节脚本返回-1表示key不存在。这个状态通常说明缓存没有预热成功或已被删除业务侧需要触发回源加载数据库库存而不是简单当作扣减失败处理。很多人在这个返回值上踩过坑把缓存失效当成库存不足用户明明看到有货却下单失败。3.3 库存缓存与数据库之间的回源策略Redis的库存不要一把梭全量加载到缓存里更稳妥的做法是按需预热。比如商品详情页被访问时异步检查该sku的库存key是否存在不存在则从数据库加载可售库存并设置过期时间。这样既避免了大促时全量预热耗费时间又能让不热门的商品不占用Redis内存。回源时要小心一个覆盖问题如果数据库库存是100缓存key过期了此时有一个请求正在执行扣减另一个请求回源加载了100覆盖进去就会把扣减后的数值重新顶回去导致超卖。解决办法是回源时使用SETNX而非SET如果key已存在就放弃加载。另外给库存key设置过期时间时要留足余量比如10分钟过期时间会比5分钟安全得多避免热点key频繁回源。3.4 Redis不可用时的降级方案任何引入Redis的方案都要回答一个问题Redis挂了怎么办我的建议是宁可牺牲一点可用性也不能牺牲一致性。Redis不可用时的降级方案可以分为两档普通商品直接走数据库扣减此时并发量通常可控数据库的压力也能承受。大促热点商品降级到限流拒绝策略即直接提示用户稍后再试。不要试图在这种情况下强行依赖数据库去兜底热点SKU的数据库扣减大概率会打崩整个库牵连其他商品的正常下单。还有一个容易忽略的点Redis和数据库的一致性。我见过不少团队上了Redis之后数据库里的库存数值形同虚设最后Redis数据一丢整个库存账目全乱了。正确做法是Redis只作为扣减校验的前端层所有经过Redis扣减的流水都必须异步写一份到数据库库存流水表中这样Redis即使清了缓存也能通过流水重建库存数据。4. 订单与库存的一致性保障方案4.1 一个典型的订单库存分布式事务困境订单与库存一旦分离到不同的存储或服务里就会产生分布式事务问题。最典型的场景是这样的用户下单请求进来了先扣Redis库存扣减成功后开始插入订单记录。此时如果插入订单失败库存就凭空少了一部分用户没有得到订单平台也丢了这个库存。反过来也一样订单创建成功但库存扣减超时或失败用户看到订单存在系统里却没有真实的库存后续发货的时候就会卡住。解决这个问题的核心思路不是强一致而是最终一致 对账兜底。具体到代码层面我先说一下我自己惯用的处理流程请求进入下单接口先通过Redis原子扣减库存扣减成功后创建一条预订单记录状态为待确认并携带本次扣减的唯一业务流水号预订单落库成功后再异步通知订单服务真正创建正式订单正式订单创建成功将预订单状态更新为已确认如果正式订单创建失败触发库存回补逻辑并把预订单标记为已回补定时任务扫描一段时间内仍未确认的预订单进行状态判断和补偿。这种设计的好处是把库存扣了和订单建了解耦成两个步骤中间通过预订单和流水号把它们关联起来。任何一个环节失败都有据可查有专门的补偿任务去恢复一致性。4.2 状态机是订单一致性的骨架订单系统的状态流转建议一开始就引入状态机而不是散落各处用if-else判断。比如一个标准订单的状态机至少包含待支付预订单已确认等待用户支付已支付用户支付成功库存进入待出库状态已取消用户主动取消或超时关闭锁定库存释放已发货仓库发货库存正式出库已完成用户确认收货交易闭环售后中退款/退货流程启动可能需要回补库存状态机的好处不仅仅是代码结构清晰更重要的是它能定义合法状态转移路径。比如已取消的订单不能直接跳到已发货这种非法状态流转会在代码层面被拦截避免脏数据扩散。我见过不少团队的订单表状态字段就是简单的int代码里到处散落着if (order.status 2) doSomething()到了后来加新状态时根本不知道会有多少地方被影响。引入状态机之后每个状态变更都走统一入口相关的库存操作、流水记录、消息推送全都能挂在这一个口子上。4.3 定时对账任务一致性兜底的关键不管前面设计得多么严密线上总会遇到各种极端情况进程莫名其妙被杀掉了、消息积压了、回调超时了、开发上线时把接口调错了等等。这时候唯一的救命稻草就是定时对账任务。我的对账任务分为三个级别分钟级扫描待支付订单超过支付时限则关闭订单并释放库存。这保证锁定的库存能被及时回收。小时级扫描已支付但物流系统仍未扣减出库的订单核对库存流水同时核对Redis库存和数据库流水之间的差额。日级全量核对库存台账、订单台账、流水台账三者是否一致输出差异报表给运营人工复核。日级对账可能在手工处理的传统企业里不太必要但凡是和线上资金、库存相关的系统这个任务绝对值得投入开发成本。一套指标维度多、告警精准的对账脚本在故障排查时提供的价值甚至超过监控大盘。4.4 消息队列在下单链路中的角色很多方案会把MQ放在下单链路里做主流程比如下单成功-发送消息-订单服务消费创建订单。我的经验是消息队列不要参与主链路的数据强一致操作它更适合做异步解耦和流量削峰。原因很简单MQ会增加链路的长度和不确定性。万一消费者挂了、消息丢失或者重复投递用户端会直接感知到下单异常。所以我的做法是核心的下单、扣库存、创建订单仍然同步处理保证用户能实时看到结果MQ只用来处理非实时性的通知任务比如发短信、推送物流信息、更新推荐系统的行为数据等。至于流量削峰下单接口本身就应该做限流而不是指望着把请求先全揽进MQ里慢慢消化。大流量先削掉能进入业务逻辑的请求基本都是峰值内可服务的这样整个系统都能处于可控状态。5. 高并发下单接口的整体架构落地方案5.1 分层保护网关层、应用层、数据层高并发下每一个层级的防护目标不一样不能把希望寄托在某一层单独扛住所有压力。我的通用分层思路是网关层做全局限流、IP维度黑白名单、接口维度流量控制把明显恶意或重复的请求挡在最前面。应用层做热点SKU维度的本地限流比如单机每秒最多处理100个某SKU的下单请求以及基于分布式锁的库存预校验。数据层Redis扛库存扣减的热点操作数据库负责持久化和对账。以某次模拟大促为例订单接口每秒承接的请求量是5000左右网关层先过滤掉一部分非法的或重复提交的请求把真正进入逻辑的流量压到3000。应用层每个节点再按SKU维度限流最终真正落库和扣Redis的请求约每秒2000这个量级在加了索引和分表之后数据库是可以平稳承接的。5.2 接口层的防重设计在高并发下用户重复提交和系统重复下单是两个不同的概念。前者是用户手一抖点了两次后者是服务端的重试机制或消息重复投递导致的。无论哪个防止重复下单都必须在代码层面做掉。我的做法是在进入下单逻辑前先做一次分布式幂等校验// 幂等key用户ID 商品SKU 本次提交的请求唯一标识 String idempotentKey userId : skuId : clientRequestId; Boolean firstSubmit redisTemplate.opsForValue() .setIfAbsent(idempotentKey, 1, Duration.ofMinutes(30)); if (!Boolean.TRUE.equals(firstSubmit)) { throw new RepeatSubmitException(重复提交请勿频繁操作); }这个幂等key的过期时间要和预订单超时关闭时间对齐确保订单关闭后用户再次购买同一商品时不会因为幂等key还在而被拦截。还有一种更严格的做法在下单请求的token里嵌入本次请求的唯一标识由前端生成并提交后端利用数据库的唯一索引来兜底。user_id sku_id request_id建联合唯一索引如果插入时出现唯一键冲突直接判定为重复请求。5.3 热点SKU隔离和本地缓存大促活动中真正产生高并发的SKU数量其实并不多通常几十个到几百个而已但它们占了绝大部分流量。把这些热点SKU和普通SKU放在同一个链路里处理普通商品的请求会被热点商品的加载拖累。我习惯的做法是在缓存层面给热点SKU建单独的key前缀比如hot_stock:skuId并且在应用层面预热一份SKU的本地缓存Caffeine本地缓存里存的是该SKU的库存判断阈值而不是库存数值本身。比如某热点SKU设定单机本地最多放行1000个请求这1000个请求再到Redis去扣减其余的直接快速返回拥挤请稍后重试。这种做法本质上是把远端压力转化为本地提前拦截对保护后端非常有帮助。本地缓存要注意避免内存占用过高的问题只针对配置了白名单的热点SKU生效并且定期刷新配置不热了就及时摘除防止商品热度下降后仍然占用本地内存。5.4 数据库层面的辅助手段即使Redis扛住了绝大部分读和扣减操作数据库仍然需要处理预订单插入、状态更新和库存流水入账等写操作。这些写操作虽然没有库存扣减那样的单行热点但高并发下同样可能把数据库压垮。我自己处理数据库压力的经验有几点订单表按订单号做哈希分表比如拆64张表避免单表数据量过大导致的索引性能衰减。插入操作异步化预订单的落库可以先用内存队列缓存一批批量写入数据库减少小事务的开销。关键查询走只读从库订单列表、库存查询这些只读操作走从库主库专心处理写操作避免慢查询拖垮写入性能。控制单事务的范围一个事务里只做必要的写入不要把远程调用、消息发送等耗时的逻辑放在事务里否则事务时间越长锁冲突概率越大。还有一个经常被忽略的点数据库连接池的大小要合理设置。比如服务实例数是20个每个实例连接池配置50那就是1000个数据库连接。数据库能同时处理的连接数是有限的连接数越大不一定性能越好反而可能造成上下文切换开销过大。连接池建议控制在CPU核数*2到CPU核数*4之间留出余量即可。6. 实战中的常见问题与排查技巧6.1 疑难杂症的定位思路高并发的故障往往不会只挂在某一个点上更多时候是多个组件互相影响。我这里整理了几个典型的排查场景和思路非常实用。场景一Redis CPU突然飙升请求大量超时先别急着加Redis节点先查是不是有大key操作。库存扣减的Lua脚本是O(1)级别的不会导致CPU飙升更常见的情况是某个开发为了省事把几千个SKU的库存放在一个大Hash里然后遍历这个Hash做扣减。这种操作会瞬间打满Redis的单线程CPU。经验做法是一个SKU一个key不要共用一个大key。场景二订单创建成功但库存流水缺失这类问题多半出在异步任务丢失上。排查思路是先去预订单表看状态如果预订单是已确认但库存流水表里没有对应记录就说明订单创建成功后的流水写入这个环节出了问题。解决办法是给订单已确认和库存流水已写入这两个状态之间加一个事务性绑定要么同时成功要么同时失败。场景三同一用户同时提交了两个订单都扣了库存这种问题就是幂等key没生效。排查时先看请求的唯一标识是否由前端传入并透传到了后端再看幂等校验是否放在扣库存之前。很多团队把幂等校验放在了订单创建之后实际已经晚了——库存早就扣了。6.2 排查工具和命令清单排查高并发链路问题没有趁手的工具会很痛苦。我个人常用的排查手段包括redis-cli --latency快速查看Redis响应延迟redis-cli --bigkeys扫描大key定位Redis慢查询的元凶SHOW PROCESSLIST查看MySQL当前运行的SQL找慢查询和锁等待EXPLAIN分析核心SQL确认是否命中联合索引Arthas结合trace命令定位应用层接口耗时分布另外强烈建议下单链路的所有关键步骤都打上链路日志traceId贯穿全链路不要靠猜测来排查问题。日志里需要包含请求参数、库存扣减结果、订单创建结果、耗时统计。有了这些数据绝大多数问题可以在一分钟内锁定。6.3 常见问题速查表症状可能原因排查重点解决方案库存扣成了负数缺少原子化扣减race condition扣减操作是否用了事务/Lua使用Redis Lua脚本或SQL带条件扣减库存扣减成功但订单未生成跨服务调用失败没有补偿机制预订单状态、流水记录引入最终一致方案定时对账同一用户重复下单幂等校验缺失或失效幂等key是否在扣库存前校验引入分布式幂等锁唯一索引兜底下单接口RT突然拉长数据库行锁堆积或Redis阻塞慢SQL、Redis bigkey热点SKU隔离、加索引、减小事务缓存key失效后库存不准并发回源覆盖已扣减数值回源是否使用SETNX回原使用SETNX给key设置长过期时间大促时普通商品被热点商品拖垮缺少热点隔离链路日志看慢请求集中在哪些SKU热点SKU本地缓存限流、单独兜底策略6.4 线上故障的止损三板斧就算方案设计得再完善线上还是会出现意料之外的情况。这时候最重要的是快速止损保住数据正确性而不是急着修复根因。第一招直接关闭下单入口或切到全站只读模式把流量彻底挡住先保住数据库和Redis不被打挂。第二招临时调低库存扣减的Redis并发上限。如果库存扣减链路本身是健康的只是下游订单创建扛不住可以降低下单接口的放行比例让系统在半流量的状态下先跑着。第三招开启人工对账。如果已经发生了超卖或库存错乱立刻启动订单一对一对账把受影响的数据捞出来人工或脚本修复。不要指望着自动补偿能处理所有边界情况大故障面前人工介入反而是最快的。7. 写在最后的实操心得整个方案从设计到落地我自己最大的感受是高并发下的订单库存处理拼的不是用了什么高深组件而是每个环节是否都有明确的状态定义和兜底逻辑。RedisLua的原子扣减是防超卖的基石但如果没有预订单、状态机、定时对账这套组合拳库存和订单迟早会在某一次故障中走丢。很多团队花大力气优化了扣库存的性能却忽略了订单状态与库存流水的一致性等到对不上账时才发现问题根本不是出在性能上而是数据本身已经乱了。还有一点想提醒的是不要把方案设计得过度复杂。如果你的业务并发根本不高直接靠数据库事务扣减就够了。架构是为业务服务的不是用来展示技术肌肉的。我自己见过不少团队明明一天的订单量才几千却硬上了一套Redis库存异步对账分库分表的组合结果维护成本远超收益。最后分享一个小经验每次大促或活动上线前一定要做一次完整的库存扣减链路演练模拟Redis宕机、数据库死锁、消息积压这些场景。准备得再充分的方案也只有在故障面前才能暴露真正的问题。这套演练我做过很多轮每次都能至少抓出一两个平时完全想不到的边界缺陷。高并发系统从来不是写出来的是不断演练和救火趟出来的。以上是我在高并发订单和库存处理方案上的一些实践总结。如果你正在做类似的设计希望能给你提供一些可落地的思路。每个系统的业务场景不同方案细节会有差异但只要守住了原子扣减、最终一致、兜底对账这三条底线系统的大方向就不会歪。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
