一种实现库存管理的方法、系统及存储介质

技术领域

本发明属于互联网技术领域，更具体地，涉及一种实现库存管理的方法、系统及存储介质。

背景技术

近年来订餐和外卖系统在互联网领域发展迅速，用户通过手机或者网站选择菜品来预订个人订餐服务。随着用户量的增多，多并发订餐对菜品的库存控制要求越来越高，同一个用户或者多个用户同时下单预订同一个菜品的时候，要如何做到并发安全减扣库存成为一个必须考虑的问题。针对多并发订餐的菜品的库存控制，普遍的做法是，有的厂家采用排他锁和共享锁，有的厂家采用悲观锁或者同步锁。

排他锁(Exclusive Locks)，又称为写锁、独占锁，在数据库管理上，是锁的基本类型之一。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。这就保证了其他事务在T释放A上的锁之前不能再读取和修改A。

共享锁又称为读锁，若事务T对数据对象A加上S锁，则事务T只能读A；其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

悲观锁(Pessimistic Lock)，是指每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。它指的是对数据被外界(包括系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制，只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在系统中实现了加锁机制，也无法保证外部系统不会修改数据)。

乐观锁(Optimistic Lock)，是指每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于写条件(write_condition)机制的其实都是提供的乐观锁。

但是上述这些解决方案都会对系统性能造成一定的影响，严重的情况可能造成死锁，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行

发明内容

针对现有技术的至少一个缺陷或改进需求，本发明提供了一种实现库存管理的方法、系统及存储介质，不需要频繁访问数据库商品库存还有多少、不阻塞其他用户、实现安全扣减库存量、内存访问库存数量，减少数据库交互。

为实现上述目的，按照本发明的第一方面，提供了一种实现库存管理的方法，包括步骤：

S1，接收用户下单请求，读取此时的库存数据及库存版本号；

S2，接收订单提交请求并将步骤S1读取的库存版本号添加到订单提交请求，订单提交请求中还包括下单数量；

S3，对所有订单提交请求执行redis分布式锁操作，每个订单提交请求作为一个事务存放在事务队列中，按照事务队列中存放的顺序依次对每个订单提交请求执行步骤S4；

S4，判断订单提交请求是否可以处理成功，并在订单提交请求处理成功后使用乐观锁机制更新库存数据及库存版本号。

优选的，所述S4包括子步骤：

S41，再次读取此时的库存版本号，比较订单提交请求中的库存版本号和此时的库存版本号是否一致，若一致，执行步骤S42，若不一致，则执行步骤S43；

S42，向前端下单界面返回订单提交成功信息并使用乐观锁机制更新库存数据及库存版本号；

S43，用最近一次读取的版本号覆盖订单提交请求中的库存版本号，再次读取此时的库存数据及库存版本号，根据此时的库存数据判断库存是否足够，若足够则比较订单提交请求中的库存版本号和此时的库存版本号是否一致，若一致，则执行步骤S42，若不一致，则再次执行步骤S43，直至满足预设结束条件。

优选的，所述S42还包括：若接收到物品取走请求，则使用触发器机制触发物品销量。

优选的，所述S42还包括：若接收到订单取消请求或者在预设时间内没有接收到物品取走请求，则使用触发器机制触发库存数据恢复为上一库存版本号对应的库存数据，并更新库存版本号。

优选的，所述方法在服务器上执行。

按照本发明的第二方面，提供了一种实现库存管理的系统，包括：

读取模块，用于接收用户下单请求，读取此时的库存数据及库存版本号；

接收模块，用于接收订单提交请求并将读取模块读取的库存版本号添加到订单提交请求，订单提交请求中还包括下单数量；

分布式锁操作模块，用于对所有订单提交请求执行redis分布式锁操作，每个订单提交请求作为一个事务存放在事务队列中，按照事务队列中存放的顺序依次对每个订单提交请求执行步骤S4；

订单处理模块，用于判断订单提交请求是否可以处理成功，并在订单提交请求处理成功后使用乐观锁机制更新库存数据及库存版本号。

优选的，所述订单处理模块用于实现以下子步骤：

S41，再次读取此时的库存版本号，比较订单提交请求中的库存版本号和此时的库存版本号是否一致，若一致，执行步骤S42，若不一致，则执行步骤S43；

S42，向前端下单界面返回订单提交成功信息并使用乐观锁机制更新库存数据及库存版本号；

S43，用最近一次读取的版本号覆盖订单提交请求中的库存版本号，再次读取此时库存数据及库存版本号，根据此时的库存数据判断库存是否足够，若足够则比较订单提交请求中的库存版本号和此时的库存版本号是否一致，若一致，则执行步骤S42，若不一致，则再次执行步骤S43，直至满足预设结束条件。

优选的，所述S42还包括步骤：若接收到物品取走请求，则使用触发器机制触发新增物品销量。

优选的，所述S42还包括：若接收到订单取消请求或者在预设时间内没有接收到物品取走请求，则使用触发器机制触发库存数据恢复为上一库存版本号对应的库存数据，并更新库存版本号。

按照本发明的第三方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的方法。

总体而言，本发明与现有技术相比，具有有益效果：

(1)本发明提供的基于触发器实现食堂菜品库存管理的方法，采用数据库触发器+redis原子操作+sql乐观锁机制，不需要频繁访问数据库商品库存还有多少、不阻塞其他用户、实现安全扣减库存量、内存访问库存数量，减少数据库交互；

(2)本发明提供的基于触发器实现食堂菜品库存管理的方法，可以实现菜品管理，菜品上下架、菜品统计等功能，能接入到预约订餐，用户支付等系统，具有可扩展性；

(3)本发明提供的基于触发器实现食堂菜品库存管理的方法，可以针对高并发订餐额外优化，减少系统运行负担，有效提升了用户的体验。

附图说明

图1是本发明实施例的系统架构图；

图2是本发明实施例的管理员操作流程图；

图3是本发明实施例的用户操作流程图；

图4是本发明实施例的业务逻辑实现流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

与本发明实施例有关的术语解释如下。

Redis(Remote Dictionary Server)，即远程字典服务，是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、关键值(Key-Value)数据库，并提供多种语言的API。Redis是基于内存的数据结构存储器，可以用作数据库、缓存和消息中间件。Redis也以消息队列的形式存在，作为内嵌的List存在，满足实时的高并发需求。

触发器是与表有关的数据库对象，在满足定义条件时触发，并执行触发器中定义的语句集合。触发器的这种特性可以协助应用在数据库端确保数据的完整性。它不同于存储过程，主要是通过事件触发而被执行的，即不是主动调用而执行的；而存储过程则需要主动调用其名字执行。可在写入数据前，强制检验或者转换数据(保证护数据安全)，触发器发生错误时，前面用户已经执行成功的操作会被撤销。

如图1所示，本发明实施例提供的一种实现库存管理的方法应用的系统架构包括用户层、表现层、业务逻辑层和数据层。

用户层的用户分为管理者和用户；表现层用于提供用户录入菜品库存和预约订餐操作。

数据层将设施层采集的数据归类，主要分为用户数据、基础数据、业务数据进行分类存储，实现对各种数据的处理和接口服务管理，为不同数据访问提供数据交换机制，以及为外部提供数据统一访问接口。

业务处理层用于监听用户下单请求(添加商品至购物车的指令)和订单提交请求，发出商品库存请求；并用于传输到后台处理库存运算逻辑功能，用redis原子操作+sql乐观锁机制处理多并发订餐请求，使用触发器处理销量以及订单状态变更导致的库存变更。业务处理层可以在服务器上实现。

如图2所示，本发明实施例提供的实现库存管理的方法可以应用在食堂菜品的库存管理中，但是也可以应用在其他库存管理中，在不同场景的库存管理方法原理相同。以下以菜品库存管理为例。

在管理员侧的操作流程图，包括以下步骤：

S1：在管理后端添加菜品信息；

S2：设置菜品上架日期和餐次，同时设置上架菜品库存。

如图3所示，本发明实施例提供的基于触发器实现库存管理的方法在用户操作侧的流程图，包括以下步骤：

S1：选择订餐日期和餐次；

S2：选择订餐菜品加入到购物车，编辑购物车菜品数量；

S3：判断购物车菜品数量是否超过当前库存，若为是进入步骤S2，否则进入步骤S4；

S4：提交订餐订单；

S5：判断订单菜品数量是否超过当前库存，若为是进入步骤S2，否则进入步骤S6；

S6：系统生成订单，用户可以在订单确认前取消订单或者支付完成取餐。

如图4所示，本发明实施例提供的基于触发器实现库存管理的方法的业务逻辑实现流程包括以下步骤：

S1，接收用户下单请求，读取此时的库存数据及库存版本号。

用户下单请求可以是例如添加商品至购物车的指令，业务层监听到用户下单请求后，从后台数据库读取此时的库存数据及库存版本号。将库存数据返回给前端界面显示给用户，用户只能添加的下单数量必须小于库存数据，才能点击订单提交。

S2，接收订单提交请求并将步骤S1读取的库存版本号添加到订单提交请求，订单提交请求中还包括下单数量。

业务层接收到用户的订单提交请求，订单提交请求中包括下单数量及步骤S1读取的库存版本号。

S3，对所有订单提交请求执行redis分布式锁操作，每个订单提交请求作为一个事务存放在事务队列中，按照事务队列中存放的顺序依次对每个订单提交请求执行步骤S4。

具体的：分布式锁是控制分布式系统之间同步访问共享资源的一种方式。在分布式系统中，常常需要协调各系统的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。分布式锁控制线程对资源的争抢，既能保证高效并发，也能保证操作的正确。

redis分布式锁的实现：主要用到的redis函数是setnx()，首先是将某一任务标识名作为键存到redis里，并为其设个过期时间；对于再次请求过来，先是通过setnx()看看是否能插入到redis里，可以的话就返回true，不可以就返回false。

S4，判断订单提交请求是否可以处理成功，并在订单提交请求处理成功后使用乐观锁机制更新库存数据及库存版本号。

对所有处理成功的订单提交请求执行乐观锁机制，即每个订单请求处理成功后，会在菜品库存数据表中更新库存数据，并且修改数据版本号version字段，表示数据被修改的次数，当库存数据被修改时，version值会加一。

优选的，所述步骤S4包括子步骤：

S41，再次读取此时的库存版本号，比较订单提交请求中的库存版本号和此时的库存版本号是否一致，若一致，执行步骤S42，若不一致，则执行步骤S43。

由于接收下单请求和处理订单提交请求是有延时的，因此对于同一用户，接收其下单请求时读取的库存数据及库存版本号有可能和处理订单提交请求时的库存数据及库存版本号是不同的，因此需要通过比较库存版本号来判断库存是否有变动。

S42，向前端下单界面返回订单提交成功信息并使用乐观锁机制更新库存数据及库存版本号。

若经过步骤S41比较订单提交请求中的库存版本号和此时的库存版本号的一致，则表示库存数据自下单后未被修改，则库存肯定可以满足订单需求，则使用乐观锁机制更新库存数据及库存版本号。

采用乐观锁机制，那么每个订单提交请求处理成功都可以修改库存数据并且版本号加1，通过版本号的比对就可以知道库存数据是否一致。

S43，用最近一次读取的版本号覆盖订单提交请求中的库存版本号，再次读取此时的库存数据及库存版本号，根据此时的库存数据判断库存是否足够，若足够则比较订单提交请求中的库存版本号和此时的库存版本号是否一致，若一致，则执行步骤S42，若不一致，则再次执行步骤S43，直至满足预设结束条件。

若经过步骤S41比较订单提交请求中的库存版本号和此时的库存版本号的不一致，则表示库存数据自下单后被修改，库存不一定可以满足订单需求，则用最近一次读取的版本号覆盖订单提交请求中的库存版本号，然后再次读取此时的库存数据及库存版本号，根据此时的库存数据判断库存是否足够，若足够则比较订单提交请求中的库存版本号和此时的库存版本号是否一致，若一致则使用乐观锁机制更新库存数据及库存版本号。

预设结束条件可以设置为失败重试次数，例如再次执行步骤S43处理3次，如果3次后仍然失败，提示用户订单处理失败，要求用户重新提交。

例如假设用户A添加购物车10个数量，此时读取的商品库存是100，那么用户A可以提交订单，假设在用户A添加购物车之后，并在其提交订单前，用户B也下单20个数量并且先提交了订单，在事务队列中用户B的订单提交请求的位置靠前，则会先对用户B的订单提交请求进行处理，执行步骤S41，读取此时的库存版本号，若判断用户B的订单提交请求中的库存版本号和此时的库存版本号是否一致，若一致，执行步骤S42，若不一致，则执行步骤S43。然后按照事务队列中存放的顺序再处理用户A的订单提交请求，再次读取此时的库存版本号，比较用户A的订单提交请求中的库存版本号和此时的库存版本号是否一致。若在此之前用户B的订单提交请求处理成功，则用户A的订单提交请求中的库存版本号和此时的库存版本号肯定不一致，则执行步骤S43。

步骤S42还包括：若接收到物品取走请求(如取餐请求)，则使用触发器机制触发物品销量。

步骤S42还包括：若接收到订单取消请求或者在预设时间内没有接收到物品取走请求，则使用触发器机制执行回退处理，即触发库存数据恢复为上一库存版本号对应的库存数据，并库存版本号加1。

本发明实施例的一种实现库存管理的系统，包括：

读取模块，用于接收用户下单请求，读取此时的库存数据及库存版本号；

接收模块，用于接收订单提交请求并将读取模块读取的库存版本号添加到订单提交请求中，订单提交请求中还包括下单数量；

分布式锁操作模块，用于对所有订单提交请求执行redis分布式锁操作，每个订单提交请求作为一个事务存放在事务队列中，按照事务队列中存放的顺序依次对每个订单提交请求执行步骤S4；

订单处理模块，用于判断订单提交请求是否可以处理成功，并在订单提交请求处理成功后使用乐观锁机制更新库存数据及库存版本号。

优选的，订单处理模块用于实现以下子步骤：

S41，再次读取此时的库存版本号，比较订单提交请求中的库存版本号和此时的库存版本号是否一致，若一致，执行步骤S42，若不一致，则执行步骤S43；

S42，向前端下单界面返回订单提交成功信息并使用乐观锁机制更新库存数据及库存版本号；

S43，用最近一次读取的版本号覆盖订单提交请求中的库存版本号，再次读取此时库存数据及库存版本号，根据此时的库存数据判断库存是否足够，若足够则比较订单提交请求中的库存版本号和此时的库存版本号是否一致，若一致，则执行步骤S42，若不一致，则再次执行步骤S43，直至满足预设结束条件。

优选的，步骤S42还包括步骤：若接收到物品取走请求，则使用触发器机制触发新增物品销量。

优选的，所述S42还包括：若接收到订单取消请求或者在预设时间内没有接收到物品取走请求，则使用触发器机制触发库存数据恢复为上一库存版本号对应的库存数据，并更新库存版本号。

本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行以实现上述任一库存管理方法实施例的技术方案。其实现原理、技术效果与上述方法类似，此处不再赘述。

必须说明的是，上述任一实施例中，方法并不必然按照序号顺序依次执行，只要从执行逻辑中不能推定必然按某一顺序执行，则意味着可以以其他任何可能的顺序执行。

本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。