近期阅读了京东到家的库存系统设计。

重点描述了几个核心问题，如：

同订单重复扣减处理（订单锁+唯一性校验）
同商品库存并发扣减处理（悲观：商品锁；乐观：更新where stock > require，本质是db写的乐观锁，stock类似version，争抢严重时反复更新失败成本更高；对争抢更严重的情况如秒杀，提供的方案不是很合理（50%直接失败会导致普通的争抢也有一半失败吧？不太正常。），可能需要从做排队的方向设计，降低锁争抢带来的损耗）
分布式一致性（提单系统做回滚协调者+worker扫描订单列表兜底）
缓存在库存中的使用（未提及）（缓存一般用于详情页等读流量集中，但对库存不严格敏感的场景。实际扣减仍以唯一的库存数据为准（一般是数据库，秒杀等场景可能加载到缓存提升性能。数据库能支持复杂事务，缓存更快但逻辑需要简单））

也了解了部分库存业务逻辑（预占、可用、现货）。

可以看作是对分布式理论知识的实战经验。（理论知识可参考：分布式事务（如交易系统）_ligeforrent的博客-CSDN博客_分布式交易系统
分布式事务简介_ligeforrent的博客-CSDN博客）

原文：

京东到家库存系统架构设计_王卫东的博客-CSDN博客_京东到家库存系统架构设计

以下为原文。

京东到家库存系统架构设计

作者介绍：柳志崇，2008年计算机专业毕业，一直从事于移动移动互联网及O2O新零售业务领域的工作，参与过京东到家多个亿级PV系统的研发与架构，对高并发有着丰富的实战经验。

目前，京东到家库存系统经历两年多的线上考验与技术迭代，现服务着万级商家十万级店铺的规模，需求的变更与技术演进，我们是如何做到系统的稳定性与高可用呢，下面将会给你揭晓答案

库存系统技术架构图

上图如果进行总结下，主要体现出以下几个方面

库存系统技术架构图解释说明

Portal

通过提供商家PC端、App端解决大部分中小商家的日常运营需求，另外提供开放平台满足大中型商家系统对接与数据共享互通的问题。

Service

这个板块涵盖了整个库存最核心的C&B数据业务。

1.业务类

2.数据类

除了业务类需求外，京东到家还提供了大量有商业价值的数据供商家作业务决策，比如

3.中间件类

古人行军打仗，兵马未动，粮草先行，对于系统来说亦是如此，编码未动架构先行，架构的技术选型非常重要，在这里给大家分享京东技术体系上万码农都在使用的几个中间件。

1.MYSQL

京东到家库存系统使用的关系型数据库是MYSQL，低成本、低耦合、轻量级，总之优势多多。

2.REDIS

丰富的数据结构&众多的原子性命令支持，非常适合库存系统进行缓存查询及扣减操作。

3.ES

库存系统的数据量非常大，首先MYSQL数据库通过水平扩容来解决单表数据量过大的问题，水平扩容的规则采取的是按门店维度进行分表（1.目前京东到家还没有到分库的阶段，2.按门店维度进行分表数据量会相对均衡一些，所以没有按照商家维度进行划分）。那么在商家PC端上查询所有商品库存及维护库存时带来了难度，比如查询该商家下所有的商品有多少条，同时处于上架状态的商品有哪些……，为了解决这一难题，引入了ES，将数据统一存储在ES集群中，解决一些涉及到聚合查询的场景。

库存系统数据流转图

库存系统数据流转图解释说明：

库存系统的数据流转，指的都是销售库存的数据流转，在京东到家还有自营类业务板块，即上图中提到的城市仓，由于它涉及到采购入库及盘盈盘亏等问题所以会由一套WMS系统来支撑。
京东到家设计初衷就是希望商家下的商品各门店共享，带来的问题就是商家新建一个商品时，需要推送到商家下所有的门店中，即所有的门店均可以看到这个商品，或者商家新建一个门店时，需要将商家下所有的商品均推送到这个新建的门店中，所以这采用了MQ技术进行异步化批量处理。

写到这里，相信对大家对库存系统有了初步的了解，从上图来看功能上其实并不复杂，但是他面临的技术复杂度却是相当高的，比如秒杀品在高并发的情况下如何防止超卖，另外库存系统还不是一个纯技术的系统，需要结合用户的行为特点来考虑，比如下文中提到什么时间进行库存的扣减最合适，我们先抛出几个问题和大家一起探讨下，如有有妥不处，欢迎大家拍砖。

库存什么时候进行预占(或者扣减)呢

商家销售的商品数量是有限的，用户下单后商品会被扣减，我们可以怎么实现呢？

举个例子：
一件商品有1000个库存，现在有1000个用户，每个用户计划同时购买1000个。

（实现方案1）如果用户加入购物车时进行库存预占，那么将只能有1个用户将1000个商品加入购物车。
（实现方案2）如果用户提交订单时进行库存预占，那么将也只能有1个用户将1000个商品提单成功，其它的人均提示“库存不足，提单失败”。
（实现方案3）如果用户提交订单&支付成功时进行库存预占，那么这1000个人都能生成订单，但是只有1个人可以支付成功，其它的订单均会被自动取消。

京东到家目前采用的是方案2，理由：

用户可能只是暂时加入购物车，并不表示用户最终会提单并支付。
所以在购物车进行库存校验并预占，会造成其它真正想买的用户不能加入购物车的情况，但是之前加车的用户一直不付款，最终损失的是公司。
方案3会造成生成1000个订单，无论是在支付前校验库存还是在支付成功后再检验库存，都会造成用户准备好支付条件后却会出现99.9%的系统取消订单的概率，也就是说会给99.9%的用户体验到不爽的感觉。
数据表明用户提交订单不支付的占比是非常小的（相对于加入购物车不购买的行为），目前京东到家给用户预留的最长支付时间是30分钟，超过30分钟订单自动取消，预占的库存自动释放

综上所述，方案2也可能由于用户下单预占库存但最终未支付，造成库存30分钟后才能被其它用户使用的情况，但是相较于方案1，方案3无疑是折中的最好方案。

重复提交订单的问题？

重复提交订单造成的库存重复扣减的后果是比较严重的。比如商家设置有1000件商品，而实际情况可能卖了900件就提示用户无货了，给商家造成无形的损失

可能出现重复提交订单的情况：

（1、用户善意行为）app上用户单击“提交订单”按钮后由于后端接口没有返回，用户以为没有操作成功会再次单击“提交订单”按钮
（2、用户恶意行为）黑客直接刷提单接口，绕过App端防重提交功能
（3、提单系统重试）比如提单系统为了提高系统的可用性，在第一次调用库存系统扣减接口超时后会重试再次提交扣减请求

好了，既然问题根源缕清楚了，我们一一对症下药

（1、用户善意行为）app侧在用户第一次单击“提交订单”按钮后对按钮进行置灰，禁止再次提交订单
（2、用户恶意行为）采用令牌机制，用户每次进入结算页，提单系统会颁发一个令牌ID（全局唯一），当用户点击“提交订单”按钮时发起的网络请求中会带上这个令牌ID,这个时候提单系统会优先进行令牌ID验证，令牌ID存在&令牌ID访问次数=1的话才会放行处理后续逻辑，否则直接返回
（3、提单系统重试）这种情况则需要后端系统（比如库存系统）来保证接口的幂等性，每次调用库存系统时均带上订单号，库存系统会基于订单号增加一个分布式事务锁，伪代码如下：

int ret=redis.incr(orderId);redis.expire(orderId,5,TimeUnit.MINUTES);if(ret==1){//添加成功，说明之前没有处理过这个订单号或者5分钟之前处理过了boolean alreadySuccess=alreadySuccessDoOrder(orderProductRequest);if(!alreadySuccess){doOrder(orderProductRequest);}else{return "操作失败，原因：重复提交";}}else{return "操作失败，原因：重复提交";}

库存数据的回滚机制如何做

需要库存回滚的场景也是比较多的，比如：

（1、用户未支付）用户下单后后悔了
（2、用户支付后取消）用户下单&支付后后悔了
（3、风控取消）风控识别到异常行为，强制取消订单
（4、耦合系统故障）比如提交订单时提单系统T1同时会调用积分扣减系统X1、库存扣减系统X2、优惠券系统X3，假如X1,X2成功后，调用X3失败，需要回滚用户积分与商家库存。

其中场景1，2，3比较类似，都会造成订单取消，订单中心取消后会发送mq出来，各个系统保证自己能够正确消费订单取消MQ即可。而场景4订单其实尚未生成，相对来说要复杂些，如上面提到的，提单系统T1需要主动发起库存系统X2、优惠券系统X3的回滚请求（入参必须带上订单号），X2、X3回滚接口需要支持幂等性。

其实针对场景4，还存在一种极端情况，如果提单系统T1准备回滚时自身也宕机了，那么库存系统X2、优惠券系统X3就必须依靠自己为完成回滚操作了，也就是说具备自我数据健康检查的能力，具体来说怎么实现呢？

可以利用当前订单号所属的订单尚未生成的特点，可以通过worker机制，每次捞取40分钟（这里的40一定要大于容忍用户的支付时间）前的订单，调用订单中心查询订单的状态，确保不是已取消的，否则进行自我数据的回滚。

多人同时购买1件商品，如何安全地库存扣减

现实中同一件商品可能会出现多人同时购买的情况，我们可以如何做到并发安全呢？

伪代码片段1：

synchronized(this){long stockNum = getProductStockNum(productId);if(stockNum>requestBuyNum) {String sql=" update stock_main "+" set stockNum=stockNum-"+requestBuyNum +" where productId="+productId;int ret=updateSQL(sql);if(ret==1){return "扣减成功";}else {return "扣减失败";}}}

伪代码片段1的设计思想是所有的请求过来之后首先加锁，强制其串行化处理，可见其效率一定不高，

伪代码片段2：

String sql=" update stock_main "+" set stockNum=stockNum-"+requestBuyNum +" where productId="+productId+" and stockNum>="+requestBuyNum;int ret=updateSQL(sql);if(ret==1){return "扣减成功";}else {return "扣减失败";}

这段代码只是在where条件里增加了and stockNum>=”+requestBuyNum即可防止超卖的行为，达到了与上述伪代码1的功能

如果商品是促销品（比如参与了秒杀的商品）并发扣减的机率会更高，那么数据库的压力会更高，这个时候还可以怎么做呢
海量的用户秒杀请求,本质上是一个排序,先到先得.但是如此之多的请求，注定了有些人是抢不到的，可以在进入上述伪代码Dao层之前增加一个计数器进行控制，比如有50%的流量将直接告诉其抢购失败，伪代码如下：

public class SeckillServiceImpl{private long count=0;public BuyResult buy(User user,int productId,int productNum){count++;if(count%2=1){Thread.sleep(1000);return new BuyResult("抢购失败");}else{return doBuy(user,productId,productNum);}}}

另外同一个用户，不允许多次抢购同一件商品，我们又该如何做呢

public String doBuy(user,productId,productNum){//用户除了第一次进入值为1，其它时候均大于1int tmp=redis.incr(user.getUid()+productId);if(tmp==1){//1小时后key自动销毁redis.expire(user.getUid()+productId,3600);return doBuy1(user,productId,productNum);}else{return new BuyResult("抢购失败");}}

如果同一个用户拥有不同的帐号，来抢购同一件商品，上面的策略就失效了
一些公司在发展早期几乎是没有限制的，很容易就可以注册很多个账号。也即是网络所谓的“僵尸账号”，数量庞大，如果我们使用几万个“僵尸号”去混进去抢购，这样就可以大大提升我们中奖的概率，那我们如何应对呢

public String doBuy1(user,productId,productNum){String minuteKey=DateTimeUtil.getDateTimeStr("yyyyMMddHHmm");String minuteIpCount=redis.incr(minuteKey+user.getClientIp());// threshold为允许每分钟允许单个ip的最大访问次数if(minuteIpCount>threshold){//识别到这部分潜在风险用户时，会让这部分用户强制跳转到验证码页面进行校验//校验通过后才能继续抢购商品return getAndSendVerificationCode(user);}else{return doBuy2(user,productId,productNum);}}

库存系统的核心表结构设计

下面列出了库存系统的核心表结构，提供出来供大家在工作中能够有所参考

库存主表，命名规则：stock_center_00~99

库存流水表，命名规则：stock_center_flow_00~99

库存批量操作日志表，命名规则：batch_upload_log

京东到家库存设计（分布式系统）笔记相关推荐

库存系统难破题？京东到家来分享
http://www.sohu.com/a/194461959_467759 目前,京东到家库存系统经历两年多的线上考验与技术迭代,现服务着万级商家.十万级店铺的规模,在需求变更与技术演进中,如何做到 ...
库存系统难破题？且看京东到家如何破
京东到家库存系统架构设计目前,京东到家库存系统经历两年多的线上考验与技术迭代,现服务着万级商家十万级店铺的规模,需求的变更与技术演进,我们是如何做到系统的稳定性与高可用呢,下面将会给你揭晓答案库存 ...
京东到家数据构造平台设计与实践
文|袁盼李磊编辑|刘慧卿一前言二背景和目标三系统架构设计 3.1 系统介绍 3.2 典型功能详解四成果与展望一前言随着到家业务与小时购业务的快速发展,系统迭代日新月异,测试效 ...
大促突围：京东到家基于Canal的数据异构设计
张磊京东到家高级研发工程师 8年+软件研发经验,曾先后就职于链家地产.互动吧.寺库网等公司,任研发人员或团队leader,在解决业务系统设计落地方面拥有丰富经验: 现就职于达达-京东到家,主要负责 ...
应对618，京东到家订单系统高可用架构的迭代实战
闫文广京东到家后台研发部架构师从事支付系统.计费系统和订单履约系统等后台领域的研发,现专注于订单中心架构优化和研发相关的工作. 大家好,我是京东到家后台研发部的架构师闫文广,今天将给大家分享京东到 ...
【交易架构day4】京东到家交易系统的演进之路
背景交易系统可能不是技术难度最深的,但是业务复杂度最高的,一个订单从提交到最后真正生产成功要经历几十个系统,涉及的接口交互,MQ等可能达上百个.任何一个环节出问题都会导致这一单的异常,而且交易不像单 ...
离职当天，删库跑路，京东到家程序员被判刑
上面这个公号「涩郎」,是我的一个备用号,为了防止万一哪天大号失联,平时一周我也会发三篇左右的我的思考,读书笔记,认知感悟等文章,带领大家一起探索精神与财务自由之路. 大家好,我是校长. 昨天又有一条关 ...
京东到家交易系统的演进之路
背景交易系统可能不是技术难度最深的,但是业务复杂度最高的,一个订单从提交到最后真正生产成功要经历几十个系统,涉及的接口交互,MQ等可能达上百个.任何一个环节出问题都会导致这一单的异常,而且交易不像单 ...
京东到家甩包袱给达达路走错了合并也没
昨夜,一篇<传京东到家.58到家合并>的消息引发了不小的关注,结果今天中午出现了剧情反转,京东原定在今天宣布的"big deal"原来是并购达达,而不是58到家,选择达 ...

京东到家库存设计（分布式系统）笔记