发布时间：2022-10-1 分类： 电商动态
目前，京东的家居库存系统经历了两年多的在线测试和技术迭代。现在它服务于10,000级商家的100,000级商店，需求变化和技术演变。我们如何实现系统稳定性和高可用性？以下图片将向您揭示答案（通过强大的基础服务平台，可以一目了然地看到应用程序，JVM，Docker和物理机的所有健康指标.7 * 24小时智能监控报警器使其成为可能开发时没有必要关注监控，数据和业务相互补充。使用数据来验证业务需求，迭代业务需求，最大化业务需求。库存系统学生的发展只需要注意在大版本上线之前，相应的测试学生将跟进以帮助您测试和预防。上线后潜在的性能瓶颈）。
附录1：库存系统技术系统图
附录2：库存系统数据流程图
库存系统的架构非常有趣。从上图可以看出，这个功能实际上并不复杂，但是他面临的技术复杂性相当高。例如，如何在高并发性的情况下防止超卖，而库存系统也不是纯粹的技术系统。需要结合用户行为的特征来考虑它。例如，提到了最合适的库存扣除时间。让我们先提出几个问题，并与您讨论是否有任何问题。欢迎大家拍砖。
什么是库存优先购买（或扣除）？
商家销售的商品数量有限。用户下订单后，将扣除货物。我们怎样才能做到这一点？
例如：
一个项目有1000个股票，现在有1000个用户，每个用户计划同时购买1000个。
（实施1）如果用户在加入购物车时抢占库存，则只有一个用户将1000个商品添加到购物车。
（实施2）如果用户在提交订单时执行库存优先购买，则只有一个用户将在1000份商品提单中成功，其他人将提示“库存不足，提单失败”。
（实施3）如果用户提交订单&库存抢占当付款成功时，则1000人可以生成订单，但只有一个人可以成功付款，其他订单将自动取消。
京东的家目前正在使用选项2，原因如下：
用户可能只是临时加入购物车，并不意味着用户最终会开账单和付款。
因此，在购物车中检查和抢占库存，会导致其他真正想购买的用户无法加入购物车，但之前添加过汽车的用户还没有付款，最终损失的是公司。
选项3将导致生成1000个订单，无论是在付款前检查库存还是在付款成功后检查库存，都会导致用户准备付款条件，但是会有99.9％的系统取消订单概率，也就是说它给99.9％的用户带来不舒服的感觉。
数据显示，不支付订单的用户比例非常小（与不添加到购物车的行为相反）。目前，京东为用户预留的最长付款时间为30分钟。订单在30分钟后自动取消。自动库存发布
总之，选项2也可能是由于用户的命令先占库存但最终未支付，导致其他用户使用之前有30分钟的库存，但与选项1相比，选项3无疑是最佳折衷方案。
反复提交订单？
重复提交订单导致重复扣减库存的后果更为严重。例如，商家有1000件商品，实际情况可能卖900件，促使用户缺货，给商家造成无形损失
可能会反复提交：
用户真实行为）当用户单击应用程序上的“提交订单”按钮时，用户不会返回，因为后端界面不成功。用户认为没有操作成功并再次单击“提交订单”按钮。
用户恶意行为）黑客直接刷取提单界面，绕过应用程序端反重新提交功能
提单系统重试。例如，为了提高系统的可用性，提单系统将在第一次调用库存系统扣减界面超时后重试再次提交扣减请求。
好吧，既然问题的根本原因是明确的，我们就有一对药物
用户真实行为）用户第一次点击“提交订单”按钮后，应用程序端灰显按钮，并禁止再次提交订单
用户恶意行为）使用令牌机制。每次用户进入结算页面时，提单系统将发出令牌ID（全局唯一），当用户单击“提交订单”按钮时将使用该ID。卡ID，此时，提单系统将优先进行令牌ID验证。如果令牌ID存在&令牌ID访问号码=1，后续逻辑将被释放，否则将直接返回
提单系统重试）这种情况需要一个后端系统（如库存系统）来确保接口的幂等性，每次用订单号调用库存系统时，库存系统都会添加一个分布式事务基于订单号的锁定伪代码如下：
如何做清单数据的回滚机制
还有许多场景需要库存回滚，例如：
用户没有付款）用户在下订单后感到遗憾
用户付款后取消）用户订单&付款后感到遗憾
风控取消）风控识别异常行为，强制取消订单
耦合系统故障）例如，当提交订单时，提单系统T1还将呼叫点扣系统X1，库存扣除系统X2和优惠券系统X3。如果X1，X2成功，则对X3的调用失败，用户点和商家库存需要回滚。 。
场景1,2和3类似，这将导致订单被取消。订单中心取消后，mq将被发送出去。每个系统都可以通过取消MQ来保证它可以取消订单。尚未生成场景4订单，这相对复杂。如上所述，提货单系统T1需要启动库存系统X2和优惠券系统X3的回滚请求（订单必须附有订单号），X2 X3回滚界面需要支持幂等性。
事实上，对于方案4，仍然存在极端情况。如果提单系统T1准备回滚，它也将抓住机会。然后，库存系统X2和优惠券系统X3必须依靠自己来完成回滚操作，即自我数据健康检查的能力，具体如何实现它
您可以使用当前订单号所属订单的特征，并且您可以使用工作机制在40分钟之前检索订单（其中40必须大于用户的付款时间），并致电订单中心进行检查订单的状态，以确保它不被取消，否则自我数据回滚。
有多少人同时购买1件商品，如何安全扣除库存
实际上，同一个项目可以由多个人同时购买。我们怎样才能同时做到这一点？
伪代码片段1：
伪代码片段1的设计思想是首先锁定所有请求并强制序列化，因此效率不高，
伪代码片段2：
这段代码只是在where条件中添加和stockNum>='+ requestBuyNum以防止超卖行为并使用上面的伪代码1实现该功能
如果产品是促销品（例如参与峰值的产品），并发扣除的可能性会更高，那么数据库的压力会更大，您现在可以做些什么？
大量用户加标请求本质上是一种排序，先到先得。但是有这么多的请求注定要让一些人无法抓住。您可以在输入伪代码Dao图层之前添加计数器进行控制。 50％的流量将直接告诉它购买失败，伪代码如下：
另外，同一个用户不允许多次抢购同一个项目，我们应该怎么做？
如果同一用户拥有其他帐户来抢购同一项目，则上述策略将无效。
有些公司在开发的早期阶段几乎没有任何限制，很容易注册许多帐户。也就是说，网络的所谓“僵尸账户”是巨大的。如果我们使用数以万计的“僵尸数字”进行混合和购买，这将大大增加获胜的可能性。我们如何处理它？/P>
此外，还提供了库存系统的核心表结构设计供您参考。
库存主表，命名规则：stock_center_00~99
库存流量计，命名规则：stock_center_flow_00~99
库存批处理操作日志表，命名规则：batch_upload_log
